Timing von CAN-Nachrichten auf cRIO-9014/9112 und 9853

Hallo,

habe in der Zwischenzeit mal etwas rumprobiert und versucht deine Lösungsmöglichkeit in meinem Projekt einzubinden. Das "durchrotieren" der einzelnen IDs funktioniert und dementsprechend werden auch die Messages generiert, was ich am Array sehen kann, was ich mir vor der FPGA Interface Read/Write Control anzeigen lasse.
Die Nachricht die gesendet wird erhält nur leider die ID 0 und auch die Daten sind 0.

War mir jetzt nicht sicher, wie ich die Verbindung zur FPGA Reference aufbaue. Die beiden Schleifen hab ich außerhalb der Haupt-While-Schleife im Real-Time VI. Dort habe ich die Open FPGA VI Reference Function und für die Sensoren und Anzeige noch eine Read/Write Control in der Schleife. Habe testweise auch mal das bereits vorhandene FPGA VI Reference Out mit dem neuen Teil verbunden. Da mir in der Read/Write Control Function aber die Elemente aus der FPGA VI angezeigt werden, scheint die referenzierung ja zu funktionieren.

Schlummert da irgendwo noch ein anderer Fehler?

Grüße
Björn

Anzeige

Hallo Björn,

Zitat:Schlummert da irgendwo noch ein anderer Fehler?

Wahrscheinlich - anhand von Bildern kann man leider nur schlecht beurteilen…

Was macht das subVI, mit dem du die Botschaft vom RT-FIFO in ein U32-Array umwandelst?
Erzeugst du dort die korrekte Datenstruktur, wie sie vom FPGA erwartet wird?
Außerdem leuchtet da ein fetter CoercionDot, sowas macht mich immer nervös…

Der rote Punkt stand bei dir auch, wenn ich mich nicht irre. Hatte alle Datentypen angepasst, aber tatsächlich war dort der Fehler den ich angesprochen hatte. Die Array-Elemente waren nicht korrekt angeordnet.

Jetzt stimmt nur das Timing absolut nicht. Wenn ich die Hauptschleife mit einem 1ms Wait laufen lasse, sind es anstatt 10ms immer in etwa 110-120ms und statt 20ms in etwa 220 bis mehr als 360ms.
Ich denke mir, dass das Timing der Hauptschleife natürlich weiter runtergesetzt werden muss. Mit einem 10ms Wait ist es immernoch doppelt so viel wie gefordert.

Kann man die Erstellung der Nachrichten und das Schreiben in den FIFO irgendwie priorisieren?

Hallo Björn,

Zitat:Der rote Punkt stand bei dir auch, wenn ich mich nicht irre.

Nicht an dieser Stelle…

Zitat:Wenn ich die Hauptschleife mit einem 1ms Wait laufen lasse, sind es anstatt 10ms immer in etwa 110-120ms und statt 20ms in etwa 220 bis mehr als 360ms.

Beim FPGA habe ich es mit angewöhnt, bei der Konstante mit der Wartezeit immer das Label anzuzeigen - da sieht man dann gleich, auf welche "Einheit" die Wartezeit eingestellt ist (Takte, µs, ms).

(08.05.2015 13:21 )GerdW schrieb:  Hallo Björn,

Zitat:Der rote Punkt stand bei dir auch, wenn ich mich nicht irre.

Nicht an dieser Stelle…

Jetzt sehe ich welchen du meinst. Hast recht, aber die Messages stimmen vom Inhalt so weit.

Also ich bleibe seltsamerweise immer bei der doppelten Zeit. Wenn ich mit den 5ms in der Schleife runtergehe, dann kommt ich von der Zeit natürlich runter, aber das ist ja auch nicht Sinn der Sache die Zeit dort anzupassen. Scheinbar scheint irgendetwas an anderer Stelle auszubremsen.

edit: Hab die untere Schleife jetzt mal durch eine zeitgesteuerte Schleife ersetzt. Das Timing scheint jetzt, bis auf minimalste Abweichungen, zu stimmen. Danke für deine Hilfe bis hier her!

Hallo Björn,

Zitat:edit: Hab die untere Schleife jetzt mal durch eine zeitgesteuerte Schleife ersetzt. Das Timing scheint jetzt, bis auf minimalste Abweichungen, zu stimmen.

Wenn das Timing mit der TWL stimmt, mit einer normalen Schleife aber nicht, dann ist die CPU auf deinem cRIO anscheinend überlastet.
Wie sieht die CPU-Last auf dem cRIO aus?

Hallo,

(11.05.2015 08:44 )GerdW schrieb:  Hallo Björn,

Zitat:edit: Hab die untere Schleife jetzt mal durch eine zeitgesteuerte Schleife ersetzt. Das Timing scheint jetzt, bis auf minimalste Abweichungen, zu stimmen.

Wenn das Timing mit der TWL stimmt, mit einer normalen Schleife aber nicht, dann ist die CPU auf deinem cRIO anscheinend überlastet.
Wie sieht die CPU-Last auf dem cRIO aus?

Die CPU-Last verwundert mich sehr. Habe eben mal nachgeschaut und gesehen, dass sich der Real-Time Controller mit 100 % abmüht. Nachdem ich nochmal meine Real-Time VI unter einem anderen Namen gespeichert und einen neuen Build dieser Datei erstellt habe, ist die Last auf ca. 15 % gesunken. Testweise hab ich auch mal das Wait in der Hauptschleifen von 10 ms auf 5 ms verkürzt, wobei die Last nur um ca. 3 % gestiegen ist.

Da war ich mir dann sicher, irgendetwas beim Verteilen falsch gemacht zu haben. Hab mich an die Nachrichten für den zweiten CAN-Port gesetzt. Problem dabei: eine der 5-6 Nachrichten muss jede Millisekunde und die anderen eigentlich nur 10-500 ms gesendet werden. Hab die zeitgesteuerte Schleife auf 1 MHz Takt mit einem Intervall von 500 µs gestellt. Im Array mit den IDs ist einfach jede zweite ID die gleiche, wodurch die Nachrichte jede Millisekunden rausgehen sollten. Naja, auf jeden Fall treibt das die CPU-Last sofort nach oben, seltsam wird es jetzt aber, wenn ich die eben angelegte Struktur einfach aus dem VI entferne. Wenn ich den Build neu erstelle, verteile und als "Startup" festlege, liegt die Last nach Reboot immernoch bei 100%. Genau wie auch am Anfang.
Bleiben beim Verteilen des Builds noch irgendwelche Altlasten auf dem Controller?
Hast du eine Lösung für den zweiten CAN-Port? Deine von dir geposteter Vorschlag funktioniert ja im 5 ms Raster und zeitgesteuerter Schleife gut. Ich kann bei der cRIO überhaupt nicht abschätzen wo die Grenzen sind...

Grüße
Björn