Ereignisgesteuertes Lesen
Beim ereignisgesteuerten Lesen werden LabVIEW™-Ereignisse und ADS-Notifications zusammen verwendet. Eine ADS-Notification muss nur einmalig am Server registriert werden. Danach werden die Daten des Servers zyklisch oder on change (siehe „Transmode“ im Kapitel Kommunikations-Modi) vom Client empfangen. Der Client muss entsprechend nur eine Anfrage stellen und der Server steuert dann, ob eine neue Nachricht an den Client versendet werden muss.
Der ADS-Client in LabVIEW™ leitet die empfangenen Notifications (Datenpakete) als LabVIEW™-Event an eine Ereignisstruktur (event structure) weiter. Siehe dazu auch die LabVIEW™-Dokumentation zu User events. Die Ereignisstruktur fügt das empfangene LabVIEW™- Event in eine interne Warteschlange ein. Die Ereignisse in der Warteschlange werden von LabVIEW™ im FIFO-Prinzip abgearbeitet. Wenn die Notifications schneller empfangen werden als eine Abarbeitung der Ereignisstruktur in LabVIEW™ möglich ist, wird die Warteschlange größer. So wird sichergestellt, dass keine Notification verloren geht. Es muss beachtet werden, dass dadurch der in Anspruch genommene Speicherbedarf wächst. Dementsprechend muss berücksichtigt werden, dass ein Zeitpunkt erreicht werden muss, an dem der Speicherbedarf (die ausstehenden Events) abgearbeitet werden kann.
Es wird empfohlen, das Event Inspector Window von LabVIEW™ (View > Event Inspector Window) zu nutzen, um die Abarbeitung der LabVIEW™-Events zu beobachten.
Das Interface for LabVIEW™ bietet zwei verschiedene Betriebsarten, um ADS-Notifications kontinuierlich als LabVIEW™-Events anzumelden:
- E-Notification Single
- E-Notification Buffered
E-Notification Single
Die Betriebsart E-Notification Single leitet das empfangene ADS-Datenpaket sofort an die LabVIEW™-Ereignisstruktur weiter, erzeugt also direkt ein LabVIEW™-Event. In einem Datenpaket können mehrere Samples enthalten sein. Dafür sind der Transmode und die TCBufferSize entscheidende Parameter:
Bei Transmode „Cyclic“ wird der TwinCAT-seitige Puffer (der Größe TCBufferSize) genutzt. Hier werden die Notifications erst in den TCBuffer geschrieben und dann gebündelt an den LabVIEW™-Client versendet, wenn der Puffer gefüllt ist. So erreicht man einen höheren Datendurchsatz und belastet das Netzwerk nicht so stark mit vielen Nachrichten geringen Nutzdatenvolumens.
Beim Transmode „OnChange“ wird der TCBuffer nicht genutzt. Hier werden die einzelnen Notifications ohne Pufferung direkt an Client weitergeschickt. So empfängt der Client jede Änderung des Zustands mit minimaler Latenz und kann direkt darauf reagieren.
In LabVIEW™ entspricht das Blockdiagramm vom Prinzip dem obigen Bild. Hier laufen der Register Notification Block und die Event Structure in zwei unterschiedlichen Threads. Das Event wird nur einmal registriert und danach wird in der Ereignisstruktur auf die Notifications gewartet. Jede empfangene Notification enthält:
- Notification Handle
- Anzahl von Samples
- Array von Notification Data
- Array von ADS-Zeitstempeln
Wenn keine Notification empfangen wird, geht die Ereignisstruktur in einen Timeout.
Beispiele in LabVIEW™: Read Notification-Event Single, Read Notification-Event Multiple
E-Notification Buffered
Die Betriebsart E-Notification Buffered nutzt zusätzlich zur obigen Struktur einen Datenpuffer auf LabVIEW™-Seite. Die Puffergröße wird vom Parameter LVBufferSize beim Erzeugen des ADS-Symbols festgelegt. Hier werden die empfangenen ADS-Datenpakete zunächst in einer Zwischenschicht in den LabVIEW™-seitigen Puffer geschrieben und erst dann als LabVIEW™-Event an die Eventstruktur weitergeleitet, wenn der Puffer gefüllt wurde.
Durch dieses Vorgehen werden seltener LabVIEW™-Events erzeugt als in der E-Notification Single Variante. Durch das Hineinreicheichen von größeren Datenpaketen nach LabVIEW™ können z. B. Verarbeitungsprozesse effizienter gestaltet werden, sodass insgesamt ein höherer Datendurchsatz erreicht wird.
 | Puffergröße Das TwinCAT 3 Interface für LabVIEW™ reserviert beim Erzeugen von LVBuffer noch zusätzliche 10% Reserve-Pufferspeicher. |
Auch für diese Betriebsart sind derTransmode und die TCBufferSize die entscheidenden Parameter:
Beim Transmode „Cyclic“ wird der TCBuffer und der LVBuffer genutzt.
Beim Transmode „OnChange“ wird der TCBuffer nicht genutzt. Hier werden die einzelnen Notifications ohne Pufferung direkt an LVBuffer übertragen.
In LabVIEW™ gleicht das Blockdiagramm der Betriebsart E-Notification Single. Hier besitzt jede empfangene Notification ein zusätzliches Feld, die BufferInfo. Die BufferInfo bietet zusätzliche Informationen bezüglich des LVBuffer:
- Previous Overflow Samples: Beschreibt einen Counter, der angibt, wie oft der angelegte Puffer nicht ausgereicht hat. Beispiel: Der Puffer ist vom Nutzer mit 50 Samples angelegt worden. Wie oben beschrieben, wird intern 10% mehr Speicherplatz angelegt, also 55 Samples. Pro Notification können durch die TwinCAT-seitige Pufferung mehrere Samples übertragen werden. Ist der Puffer in LabVIEW™ bereits mit 45 Samples belegt, und kommt ein weiteres Paket mit 10 Samples, wird der maximale Puffer nicht überschritten und der Counter inkrementiert nicht. Würde das ADS-Paket hingegen mehr als 10 Samples beinhalten, würden Daten verloren gehen, da der Puffer nicht ausreicht. Der Counter inkrementiert entsprechend um Eins.
- Missing Samples: Beschreibt die Differenz zwischen empfangenen und erwarteten Samples. Beispiel: Der LabVIEW™-seitige Puffer hat 50 Samples, also werden 50 Samples erwartet. Werden aber nur 48 Samples empfangen, ist Missing Samples entsprechend Zwei.
- Buffer Usage: Puffer Verbrauch in Prozent %
Beispiel in LabVIEW™: Read Notification-Event Buffered, Read Notification-Event Multiple