Technische Notizen / OPC UA
Warum der Prototyp Command-and-Retrieve statt eines Abonnements verwendete
Wie im Prototyp meiner Masterarbeit Roh-Schwingungsdaten von einem IFM VSE100 über einen OPC-UA-Server abgerufen wurden.
Der Prototyp der Masterarbeit liest Schwingungsdaten von einem Diagnosemodul IFM VSE100 über einen OPC-UA-Server IFM VOS050 mit einem Python-Client.
Das Abonnement lieferte keine Rohdaten
Ein Abonnement ist bei OPC UA der übliche Weg, Werte bei Änderung zu erhalten. In diesem Aufbau lieferte ein passives Abonnement die Roh-Schwingungsdaten nicht. Die Rohdaten mussten ausdrücklich angefordert werden.
Ein Command-and-Retrieve-Ablauf
Der Client ruft deshalb nacheinander Methoden des Servers auf: StartRecording, dann Open, Read und Close. Die Daten kommen als JSON-Nutzlast zurück, die der Client vor der Verarbeitung dekodiert.
Übergabe der Daten an die Verarbeitung
Erfassung und Verarbeitung laufen als Producer-Consumer-Paar, verbunden über eine threadsichere Warteschlange. So hält eine langsame Verarbeitung die nächste Erfassung nicht auf.
Der OPC-UA-Teil ist Anwendung im Studienprojekt. Ich habe keinen OPC-UA-Server geschrieben und keine SPS oder Feldbusse programmiert.