MHa

Hallo Rupi, bitte melden Sie sich doch einmal mit weiteren gewünschten Details zur Funktionserweiterung bei uns. Vielleicht können wir die Anforderung zu einer künftigen DASYLab Version berücksichtigen und integrieren.

Das Thema beschreibt die Arbeitsweise der Zähler-Erfassung anhand des National Instrument NI-DAQmx Treibers für DASYLab. Dabei werden das Zusammenspiel zwischen DASYLab, der eigentlichen Zähler-Erfassung und die erforderlichen Parametrierungen durch den Anwender erklärt. Vom Anwender ist zunächst im Measurement & Automation Explorer für die genutzte NI Hardware eine neue NI-DAQmx Task zu erzeugen >> Signale erfassen > Zählergestützte Erfassung. Die beiden Parameter Rate und Zu lesende Samples können je nach gewähltem Erfassungsmodus gegebenfalls aus DASYLab heraus auch noch zu einem späteren Zeitpunkt nach Belieben geändert werden. Innerhalb von DASYLab erreicht der Anwender über das Menü Messen >> Messeinstellungen >> NI-DAQmx >> Messeinstellungen... den Konfigurationsdialog Messeinstellungen. Dort findet er auf einer zur Task gleichnamigen Registerkarte je nach gewähltem Erfassungsmodus weitere Einstellmöglichkeiten. Vor der Erläuterung weiterer Einstellmöglichkeiten ist das grundsätzliche Verständnis der Arbeitsweise der Zähler-Erfassung erforderlich. Für das NI-DAQmx Modul Zähler-Eingang steht in der Regel zur Erfassung der Messdaten kein eigener Hardware-Takt, ähnlich beispielsweise der kontinuierlichen Analog-Erfassung, zur Verfügung. Der Takt für die Erfassung ist durch DASYLab und eine hier verfügbare Zeitbasis zu stellen. Im Moduldialog kann unter Zeitbasis-Einstellungen eine geeignete Quelle hierzu gewählt werden. Mit dem Zeitpunkt der Erfassung des aktuellen Zählerstandes kann gleichzeitig eine im Moduldialog konfigurierbare Timeout-Überwachung gestartet werden. Innerhalb dieser Zeitspanne sollte der neue Messwert zur Verfügung stehen. Wenn DASYLab innerhalb des Timeouts keinen Messwert erhält, bestimmt der Anwender das weitere Verhalten des Treibers mit einer der folgenden Moduldialog-Einstellungen: - Nichts ausgeben Der Treiber übergibt keine Messwerte an DASYLab. Der Treiber kann die Zeitbasis-Einstellungen zur Datenübergabe an DASYLab oft nicht einhalten und führt keinerlei Korrekturmaßnahmen durch. - Den letzten gültigen Wert ausgeben Der Treiber übergibt den letzten gültigen Messwert an DASYLab. Wenn der Treiber keinen Messwert bestimmen konnte, übergibt der Treiber den Wert 0.0. - Wert ausgeben Der Treiber übergibt den vom Anwender eingetragenen Wert oder den Wert einer eingetragenen globalen Variablen. Einige MAX-Task-Typen für die zählergestützte Erfassung berücksichtigen die Timeout-Zeitvorgaben gar nicht, sondern verwenden eine der obigen Einstellungen, sobald keine Werte mehr eingehen. Durch Vorgabe des Wertes -1.0 ist das Überwachen des Timeouts auszuschalten. Der Anwender sollte diesen Wert verwenden, wenn die Signalquelle für unbekannte Zeitspannen nicht zur Verfügung steht und deshalb eine Timeout-Überwachung nicht sinnvoll ist.

Das Thema beschreibt die Arbeitsweise der Hardware getakteten schnellen Analog-Ausgabe anhand des National Instruments NI-DAQmx Treibers für DASYLab. Dabei werden das Zusammenspiel zwischen DASYLab, der eigentlichen Analog-Ausgabe und die erforderlichen Parametrierungen durch den Anwender erklärt. Vom Anwender ist zunächst im Measurement & Automation Explorer für die genutzte NI Hardware eine neue NI-DAQmx Task zu erzeugen >> Signale erzeugen > Analog Ausgabe. Unter Signalerzeugungsmodus ist zur Task Kontinuierlich zu wählen und die gewünschte Ausgaberate in Hz sowie Zu schreibende Samples vorzugeben. Die beiden Parameter Rate und Zu schreibende Samples können aus DASYLab heraus auch noch zu einem späteren Zeitpunkt nach Belieben geändert werden. Innerhalb von DASYLab erreicht der Anwender über das Menü Messen >> Messeinstellungen >> NI-DAQmx >> Messeinstellungen... den Konfigurationsdialog Messeinstellungen. Dort findet er auf einer zur Task gleichnamigen Registerkarte weitere Einstellmöglichkeiten. Vor der Erläuterung dieser Einstellmöglichkeiten ist das grundsätzliche Verständnis der Arbeitsweise der schnellen Hardware getakteten Analog-Ausgabe erforderlich. Im Anhang findet sich hierzu die Grafik 01.PNG. Das NI-DAQmx Modul Analog-Ausgang wird im Schaltbild durch mindestens ein vorgeschaltetes Modul mit Daten für die Ausgabe beliefert - dem Datenlieferant. Dieser Datenfluss kann je nach Schaltbilddesign in Lieferrate und Sample-Blockgröße zu den Einstellungen der NI-DAQmx Task für Rate und Zu schreibende Werte abweichend sein. Weiterhin ist nicht davon auszugehen das der Datenstrom des Datenlieferanten zeitlich äquidistant erfolgt. Dieser unterliegt den üblichen Schwankungen eines Windows 2000 / XP / Vista Betriebssystemes. Andererseits wird die Hardware zur Ausgabe mit den Vorgaben der Task einen Timer auf der Hardware starten, welcher im vorgegebenen Zeitraster der Rate die entsprechende Anzahl an Zu schreibende Werte ausgeben wird. Diese Ausgabe erfolgt zeitlich äquidistant ohne jegliche Schwankungen, bedingt durch das Betriebssystem. In der Grafik 01.PNG entspricht dies der DAQ-Hardware. Die beschriebenen Eigenschaften des Datenlieferanten und der DAQ-Hardware führen zwangsläufig zu einem Problem der Bereitstellung der Ausgabedaten. Werden zuviele Daten durch den Datenlieferanten bereitgestellt, so ergibt sich für die DAQ-Hardware ein Datenüberlauf. Werden zuwenig Daten durch den Datenlieferanten bereitgestellt, so ergibt sich für die DAQ-Hardware ein Datenunterlauf. Diese Sachverhalte führen zum Abbruch und Stop des Schaltbildes. Daher ist es zwingend erforderlich das zwischen Datenlieferant und DAQ-Hardware ein Softwarepuffer zwischengeschaltet ist. Dieser Softwarepuffer kann bis zu einem gewissen Grad die vorher beschriebenen Probleme ausgleichen. So wird des dem Datenlieferanten ermöglicht, mit seiner eigenen Rate und Blockgröße den Softwarepuffer zu befüllen und andererseits der DAQ-Hardware ermöglicht, mit der ihr notwendigen Rate und Blockgröße Daten aus dem Softwarepuffer zu entnehmen. Im Konfigurationsdialog Messeinstellungen kann nun durch den Anwender Einfluss auf diesen Softwarepuffer genommen werden. So lässt sich zunächst die Größe dimensionieren. Weiterhin besteht die Möglichkeit, den ersten Start der Ausgabe auf der DAQ-Hardware um ... Werte zu verzögern. Eine Verzögerung ist grundsätzlich immer dann sinnvoll, wenn starke Schwankungen des Datenlieferanten erwartet werden und der Softwarepuffer im Vorlauf zunächst erst einmal mit ausreichend Daten zur nachfolgenden Ausgabe bevorratet werden soll. Sinnvolle Werte für die Größe des Softwarepuffers und die Verzögerung sind schwierig zu benennen und unterliegen der jeweiligen Situation. Es bedarf hier einiger Tests des Anwenders zu einer praktikablen Dimensionierung. Grundsätzlich ist jedoch darauf zu achten das der Softwarepuffer in seiner Größe mindestens die Vorlaufdaten der Verzögerung aufnehmen kann. Speziell für den DASYLab NI-DAQmx Treiber wird weiterhin geprüft, ob der Datenlieferant mit nur maximal der Anzahl Zu schreibende Werte bereitstellt. Das Schaltbild ist für den Datenlieferanten so zu konfigurieren das er mit der Blockgröße 1 ... Zu schreibende Werte in den Softwarepuffer schreibt.

Hallo, soweit ich den Wunsch zur Ablaufsteuerung nun verstanden habe: Der Startdialog von DASYLab, z.B. zur Eingabe eines Variablenwertes, wird noch vor dem eigentlichen Start des Schaltbildes generiert. Eine asynchrone Aktion "Start der Messung" an ein Meldung-Modul kann damit noch nicht abgesetzt werden und wird erst nach dem Verlassen des Startdialoges von DASYLab zur Ausführung (also zu spät) kommen. Mit den vorhandenen Standard-Komponenten von DASYLab fällt mir hierzu damit leider kein Lösungsansatz ein. Denkbar wäre nur die Verwendung eines Extension-Toolkit-Modules, welches zu einem früheren Zeitpunkt als die Generierung des Startdialoges aus den C-Sourcen heraus ein derartiges Fenster über einen wählbaren Zeitraum x anzeigt. Das wäre machbar, jedoch speziell und damit kostenpflichtig zu entwickeln. Mfg MHa

Hallo, Unterstützung für die Einbindung von Data Translation Hardware unter DASYLab finden Sie direkt beim DT-Support www.datx.de Bitte wenden Sie sich daher an DT. Mfg MHa

Hallo, geht es grundsätzlich darum den Startdialog = Start-Bildschirm von DASYLab auszuschalten? Dies ist über den Menüpunkt Optionen >> Globale Einstellungen... und dort "Start-Bildschirm anzeigen" steuerbar. Mfg MHa

DASYLab 10.x = NI-DAQmx + CAN im Einklang mit Datenerfassung Der RTSI-Bus (RTSI = Real Time System Integration) ist ein interner, digitaler Hochgeschwindigkeitsbus zur Synchronisation verschiedener Steckkarten von National Instruments. Durch Übertragung von Takt- und Triggersignalen zwischen den Karten werden ohne externe Verkabelung oder zusätzliche Belastung des Datenbusses alle Ereignisse und Abläufe der Karten auf eine gemeinsame Zeitbasis gesetzt – sie verlaufen somit koordiniert. Mit Hilfe von RTSI können z.B. Analogeingangskarten CAN-Nachrichten auslösen. Realisiert wird der RTSI-Bus in Standard-PCs als Flachbandkabel von Karte zu Karte, sowohl auf PCI- als auch auf ATBus-Basis. In Systemen mit der „PCI Extension for Instrumentation“ (PXI) ist er Teil dieser Erweiterung von CompactPCI zu PXI. Hier ist der Bus in der Backplane parallel zum PCI-Bus angeordnet. Je nach Kartentyp werden verschiedene Signale übertragen. Analoge Datenerfassungskarten können die Zeitbasis, den Abtasttakt sowie Trigger-Ein- und -Ausgänge übermitteln und empfangen. Andere Karten synchronisieren darüber hinaus interne und externe Vorgänge. CAN-Bus-Karten erhalten ein gesteuertes Verhalten zum Senden und Empfangen von Nachrichten.

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. 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. 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. 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. 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. Ü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