Hilfe zur Automatisierung von Abläufen mit SCPI
Letztens wurde ich gefragt, ob ich schon einmal ein SCPI Device in Loxone integriert hätte. SCPI? Noch nie gehört, klang aber ganz interessant: Unbekanntes Device, kein Zugriff auf die Umgebung, keine Möglichkeit mit dem Gerät zu kommunizieren. Genau mein Ding. 🙂
Spaß beiseite. Ohne die ganzen Vorarbeiten mit meinen Projekten wäre die folgende Umsetzung nicht möglich gewesen: Testdaten mit cli_tcp, die neuen Möglichkeiten mit picoC Debugging, Einsatz von Loxmock für die lokale picoC Entwicklung und natürlich die gewonnene Erfahrung aus den bisherigen Entwicklungen. Das Beste aber war das Ergebnis: Remote lokal entwickelt, geliefert, in Loxone eingespielt, läuft. Eine kleine Nachbesserung gab es, mehr nicht. Das ist zwar nicht perfekt, aber nah dran.
Die Geburt der Steuerung für Messgeräte mit SCPI über Loxone und ein paar Downloads dazu (v02) kann man hier nachlesen.
Bisher war ich der Meinung, dass Loxone nur für die Haussteuerung verwendet wird. Da ging mein Blick aber wohl nicht weit genug… Ich durfte erfahren, dass Loxone auch für die automatisierte Steuerung von Messgeräten für Industrieanwendungen verwendet werden kann. Genau für solche Anwendungsfälle kann diese picoC basierte SCPI Lösung eingesetzt werden.
Testdaten und Loxmock
Wie schon erwähnt hatte ich keinen Zugriff auf die Zielumgebung. Deshalb habe ich mir mit cli_tcp Testdaten für einige SCPI-Kommandos Beispielanfragen samt Ergebnissen schicken lassen. Das hat gereicht um die Skripte für Loxone Config zu implementieren.
Die zugesendeten Daten habe ich im Loxmock hinterlegt und konnte so das Zielsystem simulieren. Sah in etwa so aus:
Wer sich über die Größe der Responses mit den 80 Bytes wundert: Das sind die Antwort-Blockgrößen, die immer gesendet werden. Nicht verwendete Antwort-Bytes sind aufgefüllte 0-Werte und können hier ignoriert werden.
Die Komponenten
Entstanden sind zwei picoC Skripte:
- Eines für SCPI-Reporting, also das Abfragen von Zuständen und Werten.
- Eines für SCPI-Controlling, also die Steuerung des Zieldevices anhand von eigener Logik und Kommandos. Im Anwendungsfall waren keine weiteren dynamischen Parameterübergaben notwendig. Somit war eine feste Konfigurationsvorgabe ausreichend.
Die Kommunikation mit dem Gerät funktioniert mit plain ascii Kommandos über TCP, wie auch oben zu sehen beim Abrufen der Testdaten über cli_tcp. Interessant hierbei ist, dass die Antworten nicht nur numerisch, sondern auch textuell sein können. Beispiel:
Request: STATus:OPERation
Response: READY
Zur weiteren Verarbeitung dieser Art von Antworten benötigen wir also auch eine Mapping-Möglichkeit von String zu Zahl…
Für jede der beiden nachstehend vorgestellten Komponenten werden in der Loxone Config ein Programm-Baustein und ein Textgenerator-Baustein miteinander verbunden. Der Textgenerator-Baustein muss am Eingang „Tr“ eingeschaltet werden. Sieht man dann später im Screenshot.
Der Reporter
Diese Komponente liest konfigurierte Werte aus und legt sie an die Ausgänge O1 bis O13 des Programmbausteins zur Weiterverabeitung. Dabei werden drei Datentypen verwendet: integer, float, string (über das bereits erwähnte und nachfolgend erklärte Mapping).
Die Datentyp-Angaben werden den jeweiligen Anfragen vorangestellt und mit Doppelpunkt separiert. Um die String-Rückgaben darstellbar zu machen, wird ein Mapping direkt mit angegeben. Sollte dieses nicht greifen, so ist abschließend noch ein Defaultwert anzugeben. Könnte also z.B. so aussehen:
# Usage example for SCPI queries
# Supported datatypes: i(nt), f(loat), s(tring)
#
i:OUTPut:MEasurement
f:OUTPut:UNMEasurement
s:STATus:OPERation ("IDLE"=0,"MEASURE"=1,"READY"=2,"TIMEOUT"=3,"ERROR"=4,-1)Für die Gesamtkonfiguration wie im Screenshot, sind in Summe also anzugeben:
- IP und Port
- abzufragende Werte
- Wartezeit zwischen Anfrage und Antwort
- und die Wartezeit bis zur nächsten Iteration.
Hääh? Klarer wird das mit dem Bild. 🙂
Der Controller
Da ein Messgerät nach einer bestimmten Logik gesteuert werden möchte, gibt es die Controller-Komponente.
Auch in dieser sind IP und Port anzugeben. Die konfigurierten potentiellen Steuerkommandos werden der Reihe nach den Eingängen zugeordnet. Über seine eigene Logik kann man nun das jeweilige Kommando ansteuern und damit absetzen. Dazu wird einfach am entsprechenden Eingang ein Impuls von einer Sekunde angelegt. Fertig. Nachstehend im Bild habe ich das exemplarisch mit einem Taster an Eingang I1 dargestellt. Bei Betätigung des Tasters wird ein Impuls für eine Sekunde an I1 angelegt und damit das „STARt“ Kommando abgesetzt.
Download? Hier geht’s weiter.
picoC Skript für den Reporter
picoC Skript für den Controller
Wie immer gilt: Fortschritt, nicht Perfektion… Feedback ist also jederzeit willkommen.