Kommunikations-Modi
Erste Einordnung
Die Erweiterungen der Grundfunktionalitäten, sync, async und notification, werden im Folgenden erläutert. Ebenso werden praktische Empfehlungen gegeben, welcher Modus für exemplarische Anwendungen die bevorzugte Wahl darstellt.
Folgende Tabelle zeigt alle bereitgestellten Modi mit einer ersten Einordnung.
Modus | Read | Write | Kurzbeschreibung |
|---|---|---|---|
X | X | Lesen/Schreiben einer Variablen in einer abgeschlossenen einmaligen Aktion. Der Client wartet während der Anfrage an den Server. | |
X | X | Lesen/Schreiben einer Variablen in einer abgeschlossenen einmaligen Aktion. Der Client wartet während der Anfrage an den Server nicht. | |
X |
| Warten auf ein „On Change“-Event in TwinCAT als einmalige Aktion. Die Notification wird nach dem Event abgemeldet. | |
X |
| Einmaliges Lesen einer Zeitreihe mit definierter Länge. Nach Erhalt der Zeitreihe wird die Notification abgemeldet. | |
X |
| Kontinuierliches Lesen (zyklisch oder „on change“). Die Notification wird nicht automatisch abgemeldet, sondern läuft bis sie explizit abgemeldet wird. Die empfangenen Notifications werden in LabVIEW™ an eine Ereignisstruktur weitergeleitet. | |
X |
| Gepuffertes kontinuierliches Lesen (zyklisch oder „on change“). Die Notification wird nicht automatisch abgemeldet, sondern läuft, bis sie explizit abgemeldet wird. Die empfangenen Notifications werden in LabVIEW™ an eine Ereignisstruktur weitergeleitet. Der Puffer ermöglicht einen höheren Datendurchsatz, verursacht jedoch Latenz. | |
X |
| Kontinuierliches Lesen (zyklisch oder „on change“). Die Notification wird nicht automatisch abgemeldet, sondern läuft bis sie explizit abgemeldet wird. LabVIEW-seitig werden die Daten in einen Puffer geschrieben, auf den der Nutzer direkten Zugriff hat. |
In der obigen Tabelle wird einigen Modi die Eigenschaft „Buffered“ zugesprochen. Das untere Schaubild verdeutlicht den Systemaufbau. Bei „Noti. Buffered“ und „E-Noti. Buffered“ bezieht sich der angesprochene Buffer auf einen LabVIEW™-seitigen Buffer der Größe LVBufferSize. Der Buffer wird mit Daten, welche aus TwinCAT gelesen werden, gefüllt, und beim Erreichen der Buffer-Größe an LabVIEW™ übergeben. Darüber hinaus gibt es aus dem Standard-ADS-Interface einen TwinCAT-seitigen Buffer, welcher allerdings nur bei ADS-Notifications vom Typ Cyclic verwendet werden kann. Standardmäßig ist dieser Buffer TcBufferSize = 10 Samples, kann aber parametriert werden.
Betrachtet wird im Folgenden exemplarisch obiges Beispiel mit den Parametern:
TcBufferSize = 10
LVBufferSize = 500
ADS-Notification vom Typ Cyclic mit 1 ms Sample Time (entspricht hier der Zykluszeit der SPS).
Alle 1 ms wird nun TwinCAT-seitig ein Sample in den TwinCAT-seitigen Buffer geschrieben. Nach 10 ms ist der Buffer gefüllt und wird an den LabVIEW™-seitigen Buffer übertragen. Nach dem Empfang von 50 Nachrichten mit jeweils 10 Samples, also nach 500 ms (plus Kommunikationszeit), ist der LabVIEW™-seitige Buffer gefüllt und übergibt dann das gesamte Datenpaket von 500 Samples an LabVIEW™. Entsprechend existiert eine Delay-Time von mindestens 500 ms bis zum Erhalt des Datenpakets in LabVIEW™. Die minimal zu erwartende Verzögerungszeit wird auch im Konfigurationsdialog (Edit Symbol Parameters) im unteren Teil als „Expected min delay“ angezeigt.
Parametrieren und Realisieren der Kommunikations-Modi
Die im obigen Abschnitt genannten Parameter können im User Interface (UI) des Symbol Interface eingestellt werden.
Neben der Parametrierung der ADS-Symbole ist die Grundstruktur des LabVIEW™-Programms zu beachten, welche nachfolgend skizziert ist.
Das Symbol Interface öffnet einen Dialog mit dem Target Browser und der Möglichkeit, jedes ADS-Symbol nach obiger Abbildung zu parametrieren. Der Ausgang des Symbol Interface ist eine Zeichenkette in XML-Format, welche alle selektierten ADS-Symbole und deren Parametrierung beschreibt. Diese Zeichenkette wird mit dem Init VI verknüpft. Alternativ kann das Symbol Interface die XML exportieren. Diese XML-Datei kann dann direkt an das Init VI übergeben werden. Das Init VI übergibt dann Handles der ADS-Symbole an ein Read VI, welches als polymorphic VI zu den oben beschriebenen Optionen eingestellt werden kann. Am Ausgang liegen Data-Handles, welche mit einem Type Resolver VI verknüpft werden. Der Ausgang des Type Resolver VI ist ein Variant Type, welcher in das korrekte Format gecastet werden kann. Beim Schreiben ist die Reihenfolge von Type Resolver und Write VI entsprechend vertauscht.
Die oben genannte Struktur zeigt schematisch den Aufbau mit Low Level VIs. Zur Vereinfachung in der Programmierung werden, je nach Kommunikations-Modus, mehrere Low Level VIs kombiniert. Siehe dazu z. B. Synchron Lesen oder Asynchron Lesen.
Praktische Erwägungen
Es existieren diverse Möglichkeiten zum Lesen von Daten. Um die Auswahl in der Praxis einfacher zu gestalten, ist nachfolgend eine Tabelle aufgeführt, welche exemplarische Anwendungsszenarien beschreibt und einen Kommunikations-Modus vorschlägt.
Signal-Typ in | Beispiel | Kommunikations-Modus |
|---|---|---|
Quasi-statische | Lese den aktuellen Parametersatz eines PID-Reglers oder die ID des aktuellen Produkts in der Maschine. | |
Kontinuierliches | Stream eines oder mehrerer Sensorsignale (Temperatur, Dehnung, Kraft, …). Es existiert kein definiertes Ende des Datenstroms. | Schnelle Reaktion notwendig: E-Noti. Single (Transmode „cyclic“) |
Hoher Datendurchsatz: E-Noti. Buffered oder LVB-Noti. Single | ||
Event | Warten auf TwinCAT Event, z. B. Start eines Prozesses: bStart wechselt von FALSE auf TRUE. | Noti. Single (Transmode „on change”) |
Event | Reagieren auf Veränderungen von Zuständen, z. B. Veränderung der zu lesenden Signale je nach State der Maschine: Das Event tritt häufig auf und dieses Event soll durchgängig beobachtet werden. | E-Noti. Single (Transmode „on change”) |
Signal definierter Länge | Lesen von genau 1000 Samples eines bestimmten Sensorsignals. |