Einige Fragen zu Virtuellen Devices / RAP files
Posted: 18 Mar 2020, 12:12
Liebes Kunbus Team,
Ich habe hier einige Labornetzteile welche über SCPI / LXI (tcp) angesprochen werden, und möchte diese gerne als Virtuelle Devices im Prozessabbild darstellen (ähnlicher Ansatz wie der piModbusMaster)
Dabei soll pro Labornetzteil ein virtuelles Gerät in Pictory hinzugefügt werden, und anschliessend pro Gerät die IP Adresse und der TCP Port konfiguriert werden können. Ich habe also einen kleinen Unix Daemon geschrieben, welcher auch schon mit meinen Netzteilen kommuniziert. Aktuell sind die IP Adressen / TCP ports aber noch statisch in einem Header definiert.
Mein Ziel ist es nun, dass sich der Daemon die Konfiguration der IP Adressen / Ports von der in Pictory definierten Konfiguration lädt.
Daher habe ich zunächst gemäß diesem Tutorial eine eigene RAP Datei für meine Netzteile erstellt (basierend auf der ModbusTcpMaster_20180122_1_1.rap), und kann nun Netzteile im Pictory als virtuelle Devices hinzufügen. Der Benutzer kann so die IP Adressen und Ports für jedes Netzteil im Pictory konfigurieren. Mein Daemon findet mittels Aufruf von piControlGetDeviceInfoList() heraus wie viele Devices es abzubilden gilt, und findet so auch die Offsets seiner Instanzen im Prozessabbild, soweit so gut.
Als nächstes habe ich versucht, die IP Adresse und Ports aus dem Prozessabbild dynamisch zu lesen. Der dazu relevante Teil der RAP Datei ist vom ModbusTCPMaster kopiert und ganz leicht angepasst:
Dem Benutzer wird wie erwartet in Pictory Value Pane unter IP_address und TCP_port der entsprechende "default" wert angezeigt. Der Benutzer kann jedem Netzteil eine eindeutige IP Adresse zuweisen, und nach dem speichern finden sich diese werte auch in der _config.rsc wieder.
Mein Deamon kann auch den TCP_port aus dem Prozessabbild lesen, jedoch nicht den STRING IP_address. Stattdessen bekomme ich lauter '\0'. Ich habe es auch mit piTest -rOFFSET,LEN,FORMAT versucht und es scheint tatsächlich so dass dieser Bereich des Prozessabbilds nicht initialisiert wurde.
Aus Neugierde habe ich dann das selbe Experiment mit einem ModbusTCPMaster wiederholt, und auch hier wurde nur das WORD slave_TCP_port initialisiert, aber nicht der STRING slave_IP_address.
Trotzdem kann piModbusMaser die passende TCP Verbindung zum konfigurierten slave ohne probleme aufbauen. Sehr interessant, woher kennt piModbusMaster die IP Adresse ???
Daher habe ich jetzt einen ganzen Katalog von Fragen zum RAP Format und zu den Virtuellen Devices:
1. Zur Funktion des Attribut "maxsize" in RAP Dateien:
- Zunächst einmal wird es in der RAP Dokumentation nicht erwähnt.
- In den ModbusTCPMaster.rap wird es beim STRING slave_IP_address auf 16 gesetzt, was darauf hindeutet dass es die maximale länge des STRINGs beschreibt, dies passt auch zu den Offsets der nächsten Variablen.
- In der selben ModbusTCPMaster.rap wird es beim WORD slave_TCP_port auf 65535 gesetzt, was jedoch darauf hindeuten würde, dass es auch etwas mit dem maximalen wertebereich zu tun hat (aber was???)
- In den RevPiDIO.rap wird es beim BYTE InputMode schliesslich auf 0 gesetzt. Es macht den Anschein, dass hier eine Variablen so definiert werden soll, dass Sie keinen Platz im Prozessabbild verwenden, z.B. zur Konfiguration. Wenn man sich den Offset der darauffolgenden Variablen anschaut, wird aber trotzdem Platz für 20 InputMode BYTEs reserviert. Zudem müsste im Fall eines Konfigurations-STRING ja trozdem auch eine maximale Länge spezifiziert werden können, damit Pictory die Prüfung des Formulars durchführen kann. Was also genau bewirkt maxsize = 0?
2. Die Funktion der Attribute im block "actions": Offenbar kann pictory unix daemons enablen wenn ein virtuelles Gerät hinzugefügt wird, und die entsprechenden Kommandos kann man z.B. im ModbusTCPMaster rap sehen, sie starten /usr/bin/revpi-config.
- Wenn ich das erste von mehreren Virtuellen Geräten im pictory lösche, dann wird der entsprechende Service bereits gestoppt. Ist das beabsichtigt oder ein Bug?
3. Die Funktion des Attributes "default" in RAP Dateien: Gemäß der Doku setzt es den vorgegebener Standardwert des Attributs (ein beliebiger DIN61131 Datentyp), und muss dabei aber selbst immer ein JSON String sein, der zusätzlich nicht als binary-safe angesehen werden darf, da JSON. Dieser String wird im Kernel Modul piControl in dieser Funktion in einen uint32 Wert umgewandelt.
Das bedeutet also, dass es mit dem Aktuellen Kernel Modul nicht möglich ist, Default werte zu setzen für alles was sich nicht als uint32 darstellen wie z.B. die 64bit datentypen LINT, ULINT , LWORD, LREAL, LTIME, LREAL sowie alle STRINGs und WSTRINGs.
- Wie konnte piModbusMaster trotzdem an IP Adresse von seinem slave kommen, wenn diese gar nie im Prozessabbild verfügbar war?
- Wie werden default werte für REALs gehandhabt ? Das Kernelmodul kann den float /double nicht direkt parsen (da fpu im kernelspace = tabu)?
- Habt ihr eine Vision in welche Richtung das default handling gehen soll ( userspace daemon vs kernel modul aufbohren ?) und währt ihr an Patches in diesem Bereich interessiert?
Vielen Dank und freundliche Grüsse,
Thomas Seiler
Ich habe hier einige Labornetzteile welche über SCPI / LXI (tcp) angesprochen werden, und möchte diese gerne als Virtuelle Devices im Prozessabbild darstellen (ähnlicher Ansatz wie der piModbusMaster)
Dabei soll pro Labornetzteil ein virtuelles Gerät in Pictory hinzugefügt werden, und anschliessend pro Gerät die IP Adresse und der TCP Port konfiguriert werden können. Ich habe also einen kleinen Unix Daemon geschrieben, welcher auch schon mit meinen Netzteilen kommuniziert. Aktuell sind die IP Adressen / TCP ports aber noch statisch in einem Header definiert.
Mein Ziel ist es nun, dass sich der Daemon die Konfiguration der IP Adressen / Ports von der in Pictory definierten Konfiguration lädt.
Daher habe ich zunächst gemäß diesem Tutorial eine eigene RAP Datei für meine Netzteile erstellt (basierend auf der ModbusTcpMaster_20180122_1_1.rap), und kann nun Netzteile im Pictory als virtuelle Devices hinzufügen. Der Benutzer kann so die IP Adressen und Ports für jedes Netzteil im Pictory konfigurieren. Mein Daemon findet mittels Aufruf von piControlGetDeviceInfoList() heraus wie viele Devices es abzubilden gilt, und findet so auch die Offsets seiner Instanzen im Prozessabbild, soweit so gut.
Als nächstes habe ich versucht, die IP Adresse und Ports aus dem Prozessabbild dynamisch zu lesen. Der dazu relevante Teil der RAP Datei ist vom ModbusTCPMaster kopiert und ganz leicht angepasst:
Code: Select all
"memory": [
{
"name": "IP_address",
"type": "STRING",
"offset": 48,
"maxsize": 16,
"range": {
"type": "tooltip_loop",
"values": [0,255,1]
},
"default": "192.168.1.104",
"unit": "",
"tags": "memory, string",
"edit": "1",
"order": 25,
"export": false
},
{
"name": "TCP_port",
"type": "WORD",
"offset": 64,
"maxsize": 65535,
"range": {
"type": "tooltip_loop",
"values": [0,65535,1]
},
"default": "8462",
"unit": "",
"tags": "memory, word",
"edit": "1",
"order": 26,
"export": false
}
],Mein Deamon kann auch den TCP_port aus dem Prozessabbild lesen, jedoch nicht den STRING IP_address. Stattdessen bekomme ich lauter '\0'. Ich habe es auch mit piTest -rOFFSET,LEN,FORMAT versucht und es scheint tatsächlich so dass dieser Bereich des Prozessabbilds nicht initialisiert wurde.
Aus Neugierde habe ich dann das selbe Experiment mit einem ModbusTCPMaster wiederholt, und auch hier wurde nur das WORD slave_TCP_port initialisiert, aber nicht der STRING slave_IP_address.
Trotzdem kann piModbusMaser die passende TCP Verbindung zum konfigurierten slave ohne probleme aufbauen. Sehr interessant, woher kennt piModbusMaster die IP Adresse ???
Daher habe ich jetzt einen ganzen Katalog von Fragen zum RAP Format und zu den Virtuellen Devices:
1. Zur Funktion des Attribut "maxsize" in RAP Dateien:
- Zunächst einmal wird es in der RAP Dokumentation nicht erwähnt.
- In den ModbusTCPMaster.rap wird es beim STRING slave_IP_address auf 16 gesetzt, was darauf hindeutet dass es die maximale länge des STRINGs beschreibt, dies passt auch zu den Offsets der nächsten Variablen.
- In der selben ModbusTCPMaster.rap wird es beim WORD slave_TCP_port auf 65535 gesetzt, was jedoch darauf hindeuten würde, dass es auch etwas mit dem maximalen wertebereich zu tun hat (aber was???)
- In den RevPiDIO.rap wird es beim BYTE InputMode schliesslich auf 0 gesetzt. Es macht den Anschein, dass hier eine Variablen so definiert werden soll, dass Sie keinen Platz im Prozessabbild verwenden, z.B. zur Konfiguration. Wenn man sich den Offset der darauffolgenden Variablen anschaut, wird aber trotzdem Platz für 20 InputMode BYTEs reserviert. Zudem müsste im Fall eines Konfigurations-STRING ja trozdem auch eine maximale Länge spezifiziert werden können, damit Pictory die Prüfung des Formulars durchführen kann. Was also genau bewirkt maxsize = 0?
2. Die Funktion der Attribute im block "actions": Offenbar kann pictory unix daemons enablen wenn ein virtuelles Gerät hinzugefügt wird, und die entsprechenden Kommandos kann man z.B. im ModbusTCPMaster rap sehen, sie starten /usr/bin/revpi-config.
- Wenn ich das erste von mehreren Virtuellen Geräten im pictory lösche, dann wird der entsprechende Service bereits gestoppt. Ist das beabsichtigt oder ein Bug?
3. Die Funktion des Attributes "default" in RAP Dateien: Gemäß der Doku setzt es den vorgegebener Standardwert des Attributs (ein beliebiger DIN61131 Datentyp), und muss dabei aber selbst immer ein JSON String sein, der zusätzlich nicht als binary-safe angesehen werden darf, da JSON. Dieser String wird im Kernel Modul piControl in dieser Funktion in einen uint32 Wert umgewandelt.
Das bedeutet also, dass es mit dem Aktuellen Kernel Modul nicht möglich ist, Default werte zu setzen für alles was sich nicht als uint32 darstellen wie z.B. die 64bit datentypen LINT, ULINT , LWORD, LREAL, LTIME, LREAL sowie alle STRINGs und WSTRINGs.
- Wie konnte piModbusMaster trotzdem an IP Adresse von seinem slave kommen, wenn diese gar nie im Prozessabbild verfügbar war?
- Wie werden default werte für REALs gehandhabt ? Das Kernelmodul kann den float /double nicht direkt parsen (da fpu im kernelspace = tabu)?
- Habt ihr eine Vision in welche Richtung das default handling gehen soll ( userspace daemon vs kernel modul aufbohren ?) und währt ihr an Patches in diesem Bereich interessiert?
Vielen Dank und freundliche Grüsse,
Thomas Seiler
