Jump to content
Sign in to follow this  
MHa

Arbeitsweise der CAN-Treiber (Ixxat, NI, Vector) unter DASYLab 10.x

Recommended Posts

Funktionsweise des CAN-Datenempfanges (gilt gleichermaßen für Ixxat-CAN, NI-CAN und Vector-CAN)

DASYLab erwartet den Datenstrom beim Empfangen bei vorgegebener Blockgröße kontinuierlich, lückenlos und äquidistant. Der Empfang erfolgt mit der unter Messeinstellungen getroffenen Abtastrate und Blockgröße. Ist hier beispielsweise eine Abtastrate von 9 Hz und eine Blockgröße von 9 vorgegeben, so müssen DASYLab jede Sekunde 9 Daten zur Aufrechterhaltung des kontinuierlichen, lückenlosen Datenstromes zur Verfügung gestellt werden.

post-44-1237362550_thumb.png

Zur Datenaufnahme von CAN-Telegrammen wird vom Treiber ein eigenständiger Thread verwendet. Innerhalb der Bearbeitung des Threads werden sämtliche CAN-Telegramme empfangen. Daraus werden softwarebasiert alle von der DASYLab-Applikation gewünschten Telegramme ausgefiltert und vom Treiber in einem Ringspeicher zwischengepuffert (Maximal 100000 Telegramme passen in den Ringspeicher). Jedes dieser CAN-Telegramme besitzt einen exakten Empfangszeitstempel, vergeben von der Programmierbibliothek des jeweiligen Hardware-Herstellers.

post-44-1237362845_thumb.png

Bei der Verteilung der Telegramme an die Übergabedatenblöcke für DASYLab werden die einzelnen Empfangszeitstempel der CAN-Nachrichten zur exakten Positionszuordnung innerhalb des Datenfeldes berücksichtigt.

post-44-1237362926_thumb.png

Stehen nach Start einer Datenerfassung nicht unmittelbar CAN-Nachrichten zur Verfügung, so werden vom Treiber die betroffenen Positionen der Übergabedatenblöcke bis zum Eintreffen einer ersten gesuchten CAN-Nachricht mit Nullen als Initialwert gefüllt. Steht weiterhin nach dem CAN-Nachrichtenempfang für eine Position eines Übergabedatenblockes kein Telegramm zur Verfügung, so gibt der Treiber für diese sich damit ergebende Lücke die vorherige CAN-Nachricht nochmals aus.

post-44-1237362964_thumb.png

Hinweise zum Datenempfang

Im Beispiel wird angenommen, das eine CAN-Quelle wiederholend die Datensignalfolge 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 generiert. Die einzelnen CAN-Signale werden in 10 ms Schritten (100 Hz) äquidistant erzeugt (0, dann nach 10 ms 1, dann nach 10 ms 2, ..., dann nach 10 ms 3, dann nach 10 ms 4 usw.). Unter den Messeinstellungen wird die Abtastrate mit 50 Hz und die Blockgröße mit 1 vereinbart. Unter Ausschluss jeglicher auftretender zeitlicher Jitter beim CAN Senden und Empfangen ist mit folgender Signalfolge beim Telegrammempfang zu rechnen: 0, 2, 4, 6, 8, 0, ... Jedes zweite empfangene Telegramm (Daten 1, 3, 5, 7, 9) kann bei der vorgegebenen zeitlichen 50 Hz Auflösung dem Ausgabeblock nicht mehr zugeordnet werden und wird daher ohne weitere Fehlerhinweise verworfen. Unter den Messeinstellungen wird die Abtastrate mit 100 Hz und die Blockgröße mit 1 vereinbart. Unter Ausschluss jeglicher auftretender zeitlicher Jitter beim CAN Senden und Empfangen ist mit folgender Signalfolge beim Telegrammempfang zu rechnen: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, ...Unter den Messeinstellungen wird die Abtastrate mit 200 Hz und die Blockgröße mit 1 vereinbart. Unter Ausschluss jeglicher auftretender zeitlicher Jitter beim CAN Senden und Empfangen ist mit folgender Signalfolge beim Telegrammempfang zu rechnen: 0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8, 9, 9, 0, 0, ... Bei der vorgegebenen zeitlichen 200 Hz Auflösung steht für jeden zweiten Ausgabeblock kein empfangenes Telegramm zur Verfügung, daher wird für die Lücke die vorherige CAN-Nachricht verwendet. Bei bekannter Ausgaberate, im Beispiel 100 Hz, könnte man im Idealfall bei gleicher Abtastrate mit Blockgröße 1 den Datenstrom empfangen und die Originalsignalfolge 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, ... einlesen. Leider unterliegen jedoch sowohl das CAN Senden als auch das CAN Empfangen zeitlichen äquidistanten Schwankungen. Die Folge daraus ist, das z.B. zum Zeitpunkt der Ausgabe eines Blockes das erwartete Telegramm am Zeitstempel erkennbar verspätet eintrifft. Der Treiber gibt für diese sich damit ergebende Lücke die vorherige CAN-Nachricht aus. Für den nächsten Ausgabeblock liegen dann unter Umständen zwei zeitlich passende empfangene Telegramme vor, wobei grundsätzlich das letzte verwendbare zur Ausgabe genutzt wird. Somit würde für diesen Fall z.B. die Signalfolge 0, 1, 2, 3, 4, 5, 6, 7, 8, 8, 0, ... entstehen (zweifache Ausgabe von 8, 9 wird verworfen). Eine bekannte CAN-Signalfolge, im Beispiel 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, ..., lässt sich zusammenfassend nur durch Überabtastung für das CAN Empfangen fehlerfrei reproduzieren. Im Beispiel wäre zum CAN Senden mit 100 Hz somit eine Abtastrate von >200 Hz zum CAN Empfangen zu verwenden. Obwohl eigentlich bereits digitalisiert müssen die zu empfangenden CAN-Telegramme wie "Analog-Werte" betrachtet werden, die nach den Vorgaben des Shannon-Abtasttheorem bei der Erfassung zu behandeln sind. Im Beispiel ergeben sich bei Beachtung der Überabtastung dann Signalfolgen wie 0, 0, 0, 1, 1, 2, 3, 3, 3, 4, 4, 5, 5, 6, 6, 6, 7, 8, 8, 9, 9, 0, ...Achtung, CAN Telegramme werden systembedingt nach ihrer Priorität auf den Bus gelegt. Will ein anderer Knoten zur gleichen Zeit Daten auf den Bus legen, so wird der Knoten zugelassen der ein Telegramm mit höherer Priorität hat. Nach einer kurzen Wartezeit wird dann erneut das nieder priorisierte Telegramm versucht abzuschicken. Wird dann wieder eine Kollision erfolgen, so verzögert sich das Versenden erneut. Dies bedeutet bei hoher Buslast werden CAN Telegramme immer wieder verzögert ausgegeben. Dies spiegelt sich dann auf der DASYLab Empfangsseite so wieder wie zuvor in den Beispielen beschrieben. Die Telegramme (Signale) werden dann gegebenenfalls nicht mehr "korrekt" einsortiert und es sieht so aus das sie in den Ausgabeblöcken verloren gegangen sind. Dies ist speziell bei Unterabtastung des Signals zu erwarten. Man kann niemals 100% gewährleisten, das z.B. ein Sinus 1:1 wieder sauber und glatt empfangen werden kann.

Funktionsweise der CAN-Datenausgabe (gilt gleichermaßen für Ixxat-CAN, NI-CAN und Vector-CAN)

Die CAN-Telegramme werden DASYLab bedingt asynchron ausgegeben. Beim Asynchronbetrieb wird nur der jeweils letzte Wert eines Datenblocks, der zum CAN-Senden bereitgestellt wird, zur Ausgabe auf den CAN-Bus verwendet.

post-44-1237363853_thumb.png

Über den exakten Zeitpunkt der Datenausgabe können keine Angaben gemacht werden, da diese von vielen Faktoren – wie zum Beispiel der Rechnerleistung, der Anzahl der Module im DASYLab Schaltbild usw. – abhängen.

Weiterführende theoretische Grundlagen zu CAN finden Sie unter http://www.me-systeme.de/canbus.html

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...