RevPi Messwertwandler: TCPModbus Slave & Master

Hier kannst du dein Revolution Pi Projekt der Community vorstellen
Dieter
Posts: 22
Joined: 06 Sep 2017, 16:21
Answers: 0

Re: RevPi Messwertwandler: TCPModbus Slave & Master

Post by Dieter »

Hallo Volker,

ich habe mich noch einmal intensiver mit dem Thema Modbus unter NodRed beschäftigt und mir noch div. Tutorials angesehen. Somit muss ich meine Aussage von gestern wohl revidieren.
Getreu dem Motto, was interessiert mich mein Geschwätz von gestern. :lol:
Nach meinem Verständnis stellt NodeRed keinen Master oder Slave zur Verfügung.
In der Zwischenzeit habe ich gelernt, dass man mit NodeRed einen Server (Slave) aufsetzen kann. Mir ist allerdings noch nicht ganz klar, wie dies funktioniert. Damit muss ich mich dann in den nächsten Wochen wohl noch einmal intensiever auseinander setzen. Im Moment kann ich dir nur versichern, dass die Lese- und und Schreibe-Nodes mit eurem Modbus Modul, für meine Zwecke, soweit zurecht kommen. D.h. ich kann mit meinem Master (bei mir die SAIA PCD) die gewünschten Werte einlesen und Schaltbefehle für den am RevPi angeschlossenen Feinstaubsensor senden. Also alles so wie ich es haben wollte.

Für mich bleiben somit folgende Punkte noch offen:

1. Wie kann ich erreichen, dass das RevPi nach einem Netzausfall wieder selbständig den Flow ausführt?
2. Wie kann ich Pictory wieder sichtbar bekommen?

Bisher muss ich mich immer anmelden, den RevPiCore auf der GUI starten, das Modbus Slave Modul aus- und wieder einschalten und dann NodeRed starten.

Es wäre schön, wenn Du mir hier weiterhelfen könntest.

Dieter
User avatar
volker
Posts: 1046
Joined: 09 Nov 2016, 15:41
Answers: 1

Re: RevPi Messwertwandler: TCPModbus Slave & Master

Post by volker »

okay,
also der Feinstaubsensor arbetie nicht mit Modbus, sondern über serielle Kommandos mit einer "normalen" seriellen Schnittstelle. Die steuerst Du über Pyhton an oder wie? Und der Anschluss geht über USB? Dann "USBtty0" als Schnittstelle? Oder kommunizierst Du mit dem Sensor auch über Node-Red?

Da ich das Gefühl habe, dass Du irgendwie sehr komplexe Umwege gehst, beschreibe ich Dir hier mal, wie ich die Sache gelöst hätte. Bei der USB-Kommunikation gehe ich davon aus, dass sie über einen normale TTY (serielle) Schnittstelle realisiert ist und dass einzelen Kommandos als Strings gesendet und eingelesen werden....
Ich gehe auch davon aus, dass Du mit sudo apt-get update und dann mit sudo apt-egt Upgrade die Pakete auf den aktuellen fehlerfreien Stand gebracht hast.
Außerdem gehe ich von einer intakten Netzwerkanbindung aus, bei der der RevPi eine IP Adresse von z.B. 192.168.1.21 hat. Die Modbus Dienste "Master" und "Slave" sind im Web-Status vom RevPi über einen angeschlossenen Browser unter der Registerkarte "Services" auf "Enabled" gestellt:
001.PNG
001.PNG (139.58 KiB) Viewed 7279 times
Also: Zunächst wird in PiCtory ein Modbus TCP Slave aufgesetzt. Dadurch stehen 32 Register für Ein- und 32 für Ausgaben bereit. Diese heißen "Input_1" bis "Input_32" und "Output_1" bis "Output_32". Die "Inputsd" entsprechen unter Modbus den Ausgangs-Registern, denn in Modbus ist die Bezeichnung immer aus Sicht des Masters (der Steuerung): Der Master (die Steuerung) schreibt in die Output Register oder Coils und liest aus den Input-Registern oder "Contacts". Ausnahme sind die holding-Register, die eigentlich outputs sind, aber auch wieder eingelesen werden können. Modbus stell für jeden dieser Registertypen eigene Befehle zum Lesen und Schreiben bereit. Unser Slave kann aber nur die Befehle "read input registers" (Befehlscode hex04), "read holding registers" (Befehlscode hex03) sowie "write single register" (Befehlscode hex06) und "write multiple registers (Befehlscode hex10) beantworten und verarbeiten. Dabei werden id mit "Inputxx" benannten Speicherzellen im Prozessabbild ("PA") vom RevPi für die "write" Befehle sowie den "read holding registers" Befehl bereitgestellt und die mit "Outputxx" bezeichneten Adressen im PA werden für den "read input registers" Befehl verwendet. "Input_01" enthält dabei die Werte, die in das Modbus-Register 01 geschrieben wurden und "Ouput_01" enthält die Werte, die mit "read input registers" aus der Modbus-Adresse 01 gelesen werden.

Im Valueeditor rechts unten in PiCtory belassen wir den TCP-Port auf seiner Defaulteinstellung 502, was dem üblichen Port für Modbus TCP entspricht. Die "max._modbus_TCP_connections" sind mit 10 auch okay, wir brauchen ja eigentlich nur eine Verbindung. Um nun in Python einfacher zugreifen zu können, lassen wir uns die Speicher-Adress-Offsets der PA-Werte "Input_01" bis "Input_32" sowie "Output_01" bis "Output_32" anzeigen. Dafür klicken wir bei allen diesen Wertzen im Value-Editor das Kästchen "Export" an (geht aktuell leider nur mit 64 einzelnen klicks :-( ). Dann kannst Du über "File "Save" und dann "File" "Export" mit der Option "Show only" und "Offset Liste", dann "OK" eine Liste am Bildschirm anzeigen lassen:

02.PNG
02.PNG (16.26 KiB) Viewed 7279 times
03.PNG
03.PNG (18.21 KiB) Viewed 7279 times
Wie man dort sieht, haben die Input_xx Datenworte (Modbusregister) einen Offset von 11 bis 73. Man kann ihn auch ausrechnen mit der Formel: Offset = 9 + 2 * xx.
Die Ouput_XX Datenworte (Modbusregister) haben einen Offset von 75 bis 137. Man kann ihn auch ausrechnen mit der Formel: Offset = 73 + 2 * xx.
Außerdem sieht man in der Exportliste auch Werte des RevPi Core 3, die im PA abrufbar sind: Neben Status und LED sind (wenn man den Haken Export beim Core entsprechend setzt) auch die CPU-Temperatur und Taktfrequenz als einzelne Bytes auf Offset 4 (CPU Temperatur in °C) und 5 (Frequenz in 10 MHz) abrufbar.

Wenn Du jetzt auf Komanndozeile von Linux das Kommando piTest -x aufrust, dann wird PiControl einschließlich des Modbus Slaves neu gestartet und Du kannst zum Beispielk mit piTest -r 4,1 die CPU Temperatur im Prozessorkern ablesen. Alternativ ginge das natürlich beim Kommando piTest auch mit dem symbolischen Namen: piTest -r Core_Temperatur.
Wenn Du in eines der Output_XX eine Wert hineinschreibst, dann kannst Du diesen Wert von Deinem Modbus Master aus abfragen:
Mach das einfach mal von der Kommandozeile aus: piTest -w Output_1, 12345, Das system antwortet mit "Write value 12345 dez (=3039 hex) to offset 75." Alternativ hättest Du auch so schreiben können: piTest -w 75,2,12345
Jetzt starte einen Modbus master und sende an slave mit der IP 192.168.0.21 auf Port 502 einen Modbusbefehl "Read Input Registers" auf das einzelne Register 1 aus. Der Master sollte melden, dass der slave mit 12345 als Registerinhalt geantwortet hat. Hie rmal als Beispiel so etwas mit dem Windowsprogramm Qmodmaster durchgeführt:
04.PNG
04.PNG (23.82 KiB) Viewed 7279 times
Hier siehst Du auch gleich eine wichtige Besonderheit von Modbus: Leider ist die Zählung der Register nicht so einheitlich, wie das wünschenswert wäre. Wir bei KUNBUS haben in unserem Modbus master und slave die Registernummern verwendet, die bei 1 anfangen. In den Modbustelegrammen werden aber die eigentlichen Modbsuadressen versendet, die bei 0 anfangen. Um also das register 1 zu lesen versendet der Master ein telegramm mit der Abfrage der Registeradresse 1 beim Slave. Darum steht hier unter "Start Address" beim QmodMaster eine "0".
Du könnest nun mit dem Qmodmaster auch mal einen Wert in eines unserer INPUT_xx Register schreiben. Mach das zum Beispiel so:
05.PNG
05.PNG (22.47 KiB) Viewed 7279 times
Hier schreibe ich also in das Register Nummer 4 (Adresse 3) den Wert 5431. Wenn ich jetzt dieses Register im PA auslesen will, kann ich das auf der Kommandozeile mit "piTest -r Input_4" machen. Die Anwort sieht so aus:
2 Byte-Value of Input_4: 5431 dez (=1537 hex)
Alternativ hätte ich auch mit piTest -r 17,2 auslesen können, wonach ich allerdings die beiden Bytes des registers einzeln angezeigt bekomme und sie dann selber zu einem Imtegerwert ausrechnen müsste:
55 21
Rechnung: 2 *256 + 55 = 5431
Übrigens könne ich mit dem Master über ein "Read Holding Registers das Register 4 (Adresse 3) wieder auslesen und bekäme dann eben 5431 angezeigt.

So weit Deine Modbus Slave Konfiguration. Wenn mit diesen Hilfsprogrammen alles läuft, dann solltest Du auch problemlos mit der SAIA PCD3 die Slaveregister auslesen können. Wie Du Prozesswerte mit Bash (also Kommandozeilen Scripte) in die Register hineinbekommst, habe ich Dir hier ja gezeit. Solche Scripte kann man dann auch zeitgesteuert untzer Linux starten lassen und z.B. alle Sekunde ausführen lassen. In unserem Tutorial für Modbus slave haben wir das an einem Beispiel gezeigt. Später zeige ich Dir, wie es unter Python genauso einfach geht. Node Red kannst Du getrost außen vor lassen, es erleichtert Deine Arbeit kaum sondern verkompliziert die Dinge eher, solange wir keine konfigurierbaren Knoten zum Auslesen des PA anbieten. Und da Du ja Python programmieren kannst, denke ich, Du solltest das ruhig in Python angehen. Aber dazu wie gesagt später.

Jetzt zur Masterseite:
Du ziehst in PiCtory den Modbus TCP Mater auf die Arbeitsfläche in den leeren Slot. In der WebStatus Konfiguration haben wir ihn ja bereits enabled.
Der Master kann nun zyklisch (und wirklich nur zyklisch) mit einem vorgebbaren Intervall Slaveregister beliebiger Slaves im gleichen TCP-Netzwerk abfragen. Je ein Mastermodul kann dabei nur einen einzigen Slave abfragen. In Deinem Fall hast Du ja auch nur einen Slave, nämlich das Wachendorfgateway, welcher die M-Bus Devices abfragt. Ich gehe davon uas, dass es mal eine IP 192.168.0.33 haben soll und über den Port 502 Modbusbefehle entgegen nimmt. Dann solltest Du das genau so in dem Werteeditor für den Master eingeben:
06PNG.PNG
06PNG.PNG (11.49 KiB) Viewed 7279 times
Welche Modbusregister nun überwelchen befehl Datenaustauschen, dass konfigurierst Du über die "extended Data" Maske, die Du mit der rechten Maustaste über dem Modbus-Master (Kontextmenü) abrufen kannst. Ohne Dein Wachnedorf-Gateway zu kennen gehe ich hier einfach mal davon aus, dass die 5 M-Bus-Geräte jeweils 4 Modbus Register ab 1, 11, 21, 31, 41 und 51 belegen. Ich erzeuge daher 5 Aufgaben (Zeilen) inder erweiterten Konfiguration, die jeweils 4 Register abfragen und die Ergebnisse im Prozessabbild (PA) vom RevPi hinterlegen. Dafür stehen diesen Aufgaben 32 Input WORD-Werte (also 2 Byte breit) zur Verfügung. Würdest Du unter Modbus mit "Coils" arbeiten, dann ständen Dir dafür 32 Input BOOL Werte (1 Bit Breite) zur Verfügung. Für Ausgänge (also Werte, die Du zum Gateway (Slave) sendest, stehen nestrpechend 32 Output WORDs und 32 Output BOOLs im PA zur Verfügung. Um das ein wenig übersichtlicher zu halten, gehen wir nocheinmla zurück zum Werteeditor (unten rechts auf der PiCtorySeite). Dort veränern wir nun die Namen der Prozesswerte im PA so, dass wir sie später auch wiedererkennen:
Aus "Input_Word_1" mache ich "Hzg_U_Leistung"
Aus "Input_Word_2" wird "Hzg_U_Vorlauftemp"
bis "Input_Word_20", aus dem "Strom_I" wird.
Ab jetzt kannst Du überall mit diesen Namen arbeiten, statt mit den ziemlich ananymen Angaben "Input_Word_xx"
So machen wir das dann auch in der erweiterten Daten Konfiguration:
07PNG.PNG
07PNG.PNG (25.68 KiB) Viewed 7279 times
Ich gehe hier von Voraussetzungen aus, die eventuell nicht stimmen. Diu musst hier die entsprechenden Einträge anpassen, wenn das Wachdorfgateway andere Vorgehensweisen erwartet:
Ich vernwende den Modbusbefehl "read input registers" mit den jeweiligen Startregistern 1, 11, 21, 31 und 41 uns lese alle 1000 ms jeweils 4 hintereinaderliegende Register die jeweiuls die Werte "Lesitung, Vorlauftemp, Rücklauftemp und Energie als 16 bit breite Datenworte in einem einzigen Register enthalten. Wenn bei Dir die Regioster so nicht angeordnet sind oder gar floatingpointwerte enthalten, musst Du natürlich völlig anders vorgehen!
Übrigens zwei Hinweise noch:
1) Die Spalte "UnitID" hat in der Regel unter Modbus TCP keine Bedeutung. Viele Geräte erwarten hier eine 255 oder aber manche auch eine 1. Das muss in den Unterlagen vom Wachendorfgerät stehen!
2) Wenn Du diese erweiterte Datenkonfiguration durcgeführt hast, solltest Du die Namen der PA-Werte nicht mehr abändern, sonst gehen die Zieladressen in den Aufgaben verloren oder noch schlimmer es wird in falsche PA-Adressen geschrieben.

Nach dieser Konfiguration wie immer unter "File" alles abspeichern und die Häkchen bei Export für die gewünschten PA-Werte setzen, um eine Offsetliste geenrieren zu können. Hierbei fällt Dir eventuell auf, dass es auch Werte mit der Bezeichnung "Modbus_Action_Status_x" gibt. Diese Werte auch einfach mal exportieren (ich habe sie sogar sinnvoll umbenannt). Sie dienen uns später dazu, per Software auch Fehler bei der Modbusabfrage zu erkennen und zum Beispiel beim Ausfall des Wachendorfgateways entsprechend eine Meldung an die übergeordnete Steuerung weitergeben zu können! Wenn hier ein Feherlstatus erscheint, müssen wir ihn entweder durch einen restart von PiCtory zurücksetzen oder aber gezielt durch das Beschreiben der Flags mit dem Namen "Action_Status_Reset_x" im PA (Hab ich ebenfalls sinnvoll umbenannt). Ich habe mal die Werte "Output_Word_x" auch alle mit einem Export-Haken versehen, falls Du Werte zum Gateway schicken willst...
Übrigens zu Diagnosezwecken exportiere ich auch mal "Master_Status_Reset" und "Modbus_Master_Status", die einen allgemeinen Status vom Master-Dienst melden und ein Rücksetzen erlauben.
Der Modbus Master - Teil meiner Offsetliste sieht nun so aus:

Code: Select all

Hzg_U_Leistung		 142	 //WORD  
Hzg_U_Vorlauftemp		 144	 //WORD  
Hzg_U_Rücklauftemp		 146	 //WORD  
Hzg_U_Energie		 148	 //WORD  
Ofen_Leistung		 150	 //WORD  
Ofen_Vorlauftemp		 152	 //WORD  
Ofen_Rücklauftemp		 154	 //WORD  
Ofen_Energie		 156	 //WORD  
Hzg_Leistung		 158	 //WORD  
Hzg_Vorlauftemp		 160	 //WORD  
Hzg_Rücklauftemp		 162	 //WORD  
Hzg_Energie		 164	 //WORD  
Solar_Leistung		 166	 //WORD  
Solar_Vorlauftemp		 168	 //WORD  
Solar_Ruecklauftemp		 170	 //WORD  
Solar_Energie		 172	 //WORD  
Strom_Verbrauch		 174	 //WORD  
Strom_Leistung		 176	 //WORD  
Strom_U		 178	 //WORD  
Strom_I		 180	 //WORD  
Modbus_Action_Hzg_u		 210	 //BYTE  
Modbus_Action_Ofen		 211	 //BYTE  
Modbus_Action_Hzg		 212	 //BYTE  
Modbus_Action_Solar		 213	 //BYTE  
Modbus_Action_Strom		 214	 //BYTE  
Modbus_Master_Status		 242	 //BYTE  
Output_Word_1		 243	 //WORD  
Output_Word_2		 245	 //WORD  
Output_Word_3		 247	 //WORD  
Output_Word_4		 249	 //WORD  
Output_Word_5		 251	 //WORD  
Output_Word_6		 253	 //WORD  
Output_Word_7		 255	 //WORD  
Output_Word_8		 257	 //WORD  
Output_Word_9		 259	 //WORD  
Output_Word_10		 261	 //WORD  
Output_Word_11		 263	 //WORD  
Output_Word_12		 265	 //WORD  
Output_Word_13		 267	 //WORD  
Output_Word_14		 269	 //WORD  
Output_Word_15		 271	 //WORD  
Output_Word_16		 273	 //WORD  
Output_Word_17		 275	 //WORD  
Output_Word_18		 277	 //WORD  
Output_Word_19		 279	 //WORD  
Output_Word_20		 281	 //WORD  
Output_Word_21		 283	 //WORD  
Output_Word_22		 285	 //WORD  
Output_Word_23		 287	 //WORD  
Output_Word_24		 289	 //WORD  
Output_Word_25		 291	 //WORD  
Output_Word_26		 293	 //WORD  
Output_Word_27		 295	 //WORD  
Output_Word_28		 297	 //WORD  
Output_Word_29		 299	 //WORD  
Output_Word_30		 301	 //WORD  
Output_Word_31		 303	 //WORD  
Output_Word_32		 305	 //WORD  
Action_Status_Reset_Hzg_U		 311.0	 //BOOL  
Action_Status_Reset_Ofen		 311.1	 //BOOL  
Action_Status_Reset_Hzg		 311.2	 //BOOL  
Action_Status_Reset_Solar		 311.3	 //BOOL  
Action_Status_Reset_Strom		 311.4	 //BOOL  
Master_Status_Reset		 315	 //BYTE  
Abschließend bitte noch PiControl neu starten (piTest -x oder in PiCtory unter "Tools" "Reste Driver" wählen.
Wenn Du die Wachdorf angeschlossen hast, dann solltest Du nun z.B. mit " piTest -r Ofen_Vorlauftemp" die Ausgabe der Vorlauftemperatur vom Ofen sehen:
2 Byte-Value of Ofen_Vorlauftemp: 0 dez (=0000 hex)
Bei mir natürlich 0 weil ich leider keinen Ofen und keine Wachdorf habe ;-)
Alternativ kannst den Wert auch über piTest -r 152,2 auslesen, bekommst aber 2 Byte zurückgegeben, aus denen Du Dir selber eine Integer berechnen musst.

Okay, nun haben wir auch den Master so weit durch. Also Zeit um zu zeigen, wie Du die Werte aus den PA-Werten vom Master in den Slave kopierst. Wenn Du sie dabei irgendwie manipulierne willst (Minimalwerte suchen, Durchschnitte bilden etc. dann ist das dabei naürlcih sehr leicht möglich. Es erfordert aber spezielöle Programmzeilen, die ich hier mal weglasse, weil ich ja absolut nicht wissen kann, was Du mit den Daten zwischen dem Kopieren so alles anstellen willst.

Hier der Code für ein Python script, welches die Einganswerte vom Master einfach zyklisch in den Slave kopiert. Ich gehe von einer Zykluszeit von 500 ms aus, weil wir beim Master eben einen Abfragezyklus von 1 Sekunde gewählt hatten. Somit werden wir garantiert alle Werte aus dem Wachendorf Gateway in unseren Slaveregistern aktuell bereithalten...

Code: Select all

#!/usr/bin/python3
# -*- coding: utf-8 -*-

import time    # used for the delays of the demo

# first the driver has to be opened by the "open" statement:
f = open("/dev/piControl0","wb+",0)


# now the endless loop of the demo starts ...
while 1:
    f.seek(142)   # here the offset within the process image is set: Modbus Master Input starts at byte 142 in the configuration
    x = f.read(40) # 20 registers = 40 bytes are read
    f.seek(75)   # here the offset within the process image is set: Modbus Slave Output starts at byte 142 in the configuration
    f.write(x)   # 20 registers = 40 bytes are written
    time.sleep(0.5)  
Das ist im Prinzip alles. Ist doch ziemlich simpel, oder?
Wenn Du natürlich mit wechselnden Konfigurationen arbeitest und Dein Programm dann nicht immer mit den absoluten Offsets anpassen willst, dann wird es ein wenig komplizierter, denn um mit den symboilischen Namen zu operieren musst Du ioctl Aufrufe mit Objektstrukturen durchführen. In unserem Tutorial zum Zugriff auf das PA mit Python gibt es aber dazu ein Beispiel. Noch einfacher geht es aber mit der Bibliothek von Sven Sager (RevPiModIO), wobei Du dann aber mit Objekten gut umgehen können solltest.
Bei dem kurzen Code habe ich auch jede Fehlerbehandlung weggelassen. Wenn Du hier bei diesem Code zum Beispiel einfahc malö den Netzwerkstecker ziehst, wird das Programm sich höchst wahrscheinlich nicht von sleber wieder fangen. Dazu müsstest Du dann in der Endlosschliefe mit Try / Exceptions arbeiten und/oder die Statusworte und Flags im PA zyklisch abfragen und bei Fehlern eine entsprechende Fehelerbehandlung durchführen (z.B. selber den Modbus Dienst zurücksetzen über ein Bash-Kommand "piTest -x" welches im Python Script ausgelöst wird). Aber das überlasse ich dann mal Dir, denn das ist wirklich sehr von Deiner retslichen Hardware und deren Feherlverhalten abhängig.

Nun noch ien kurzer Ausblick auf Couldfähigkeit:
Wenn Du z.B. die KUNBUS Cloud verwendest, könntest Du die vorgenannten bash-Befehle alle in der Cloudoberfläche als zyklische Abfragen konfigurieren und so zyklisch alle Prozesswerte in die Cloud zu einem Dashboard oder in den Speicher für die historische Auswertung mit diversen Abfragetools befördern. Alternativ könntest Du auf der Cloudoberfläche aber auch einen anderen Weg wählen: Du würdest den Cloud-Agenten, der auf dem RevPi dann aktiviert ist, einen oder mehrere Linux-Sockest üvberwachen lassen. sobald Du in so einen Socket etwas reinschreibst, würde der Agent diesen Wert in die zugeordnete Cloudtabelle schieben. Ich habe das hier mal beispielhaft für Hzg_U in den Code eingebaut und gehe davon aus, dass dafür ein Unix-Socket "/var/run/Hzg_U_values.sock" über die Cloudoberfläche in dem RevPi Core erzeugt wurde:

Code: Select all

# -*- coding: utf-8 -*-

import time    # used for the delays of the demo
import socket
import struct

# first the driver has to be opened by the "open" statement:
f = open("/dev/piControl0","wb+",0)
clientHzg_U_values = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
clientHzg_U_values.connect("/var/run/Hzg_U_values.sock")

# now the endless loop of the demo starts ...
while 1:
    f.seek(142)   # here the offset within the process image is set: Modbus Master Input starts at byte 142 in the configuration
    x = f.read(40) # 20 registers = 40 bytes are read
    f.seek(75)   # here the offset within the process image is set: Modbus Slave Output starts at byte 142 in the configuration
    f.write(x)   # 20 registers = 40 bytes are written
    
    # get the 4 process values form the input byte-string by using the struct library
    Leistung = struct.unpack_from('<H',x[0])[0] # unpack returns a tuple even is only one value is returned!
    Vorlauftemp=struct.unpack_from('<H',x[2])[0] # use 2 byte offset to get the second register value
    Ruecklauftemp=struct.unpack_from('<H',x[4])[0] # use 4 byte offset to get the third register value
    Energie=struct.unpack_from('<H',x[6])[0] # use 6 byte offset to get the fourth register value
    
    #write the 4 process values as 1 line inot the linux socket (CSV format)
    clientPiececountBox.send((str(Leistung) + ", " + 
                              str(Vorlauftemp) + ", " + 
                              str(Ruecklauftemp) + ", " + 
                              str(Energie) + "\n"
                             ).encode('utf-8')
                            )
    time.sleep(0.5)      #loop every 1/2 second  

So. Das war ein ziemlich lange Antwort, aber ichhoffe, dass Du damit nun besser klar kommst. Was Deine Probleme mit dem grauen Bildschirm bei PiCtory anbelangt, so hoffe ich, dass mit sudo upgrade die Probleme weg sind. Ansonsten versuche es bitte mal mit einem anderen Browser. Wir haben insbesondere bei älteren IE Browsern so was schon mal gesehen...
Viel Erfolg!
:D
Unser RevPi Motto: Don't just claim it - make it!
Dieter
Posts: 22
Joined: 06 Sep 2017, 16:21
Answers: 0

Re: RevPi Messwertwandler: TCPModbus Slave & Master

Post by Dieter »

Hallo Volker,

puh was für eine umfangreiche Antwort von dir. Da ich es für unhöflich halten würde noch länger nicht zu antworten, klaue ich mir heute ein wenig Zeit um zu antworten.

Es mag sein, dass manche Wege von mir etwas umständlich erscheinen. Aber fahre du mal nach Rom, ohne eine Landkarte zu besitzen und Du weißt nur wo Süden liegt. :lol:

Meinen gestellten Fragen bist Du einigermaßen geschickt ausgewichen, bzw. hast diese in deiner Antwort gut versteckt.

Ich fasse mein Fragen hier noch einmal zusammen:
1. Wie kann ich erreichen, dass das RevPi nach einem Netzausfall wieder selbständig den Flow ausführt?
2. Wie kann ich Pictory wieder sichtbar bekommen?
zu 1.) Damit piTest nach einem Netzausfall neu gestartet wird, gleichzusetzen mit eurem Treiber Reset den ich immer händisch in der GUI ausführen musste, habe ich rc.local benutzt. Nun wird nach einem Neustart piTest -x aufgerufen und mein Flow unter NodeRed läuft nach einem Netzausfall wieder fehlerfrei an.
zu 2.) Natürlich habe ich eine intakte Netzwerkanbindun und mindestens 10x sudo apt-get update & upgrade durchgeführt. Trotzdem wurde Pictory im Browser nur als grauer Bildschirm angezeigt. Die Lösung war recht simpel. Statt sudo apt-get upgrade habe ich dann sud apt-get full-upgrade benutzt. Dadurch wurden noch diverse Pakete nachgeladen und schon wird Pictory auch wieder angezeigt.

Damit sind diese Punkte für mich nun abgehakt.

Leider muss ich dich enttäuschen, von Python habe ich bisher noch keine Ahnung. Außer dieser "Hello World" Programmierung habe ich mich mit Python noch nichts gemacht. Du selber hast mir ganz am Anfang von Python abgeraten und in Richtung NodeRed gelenkt. Deshalb werde ich den Weg auch beibehalten. Ich komme in der Zwischenzeit damit auch immer besser zurecht. Der Feinstaubsensor macht was ers soll und muss jetzt nur noch im Freien angebracht werden. Und ja, der Feinstaubsensor erhält seine Kommandos über die serielle Schnittstelle.

Ich habe in den letzten vier Wochen aber auch wieder einen heftigen Rückschlag erlitten. Das super teure Gateway der Fa. Wachendorff bringt mich an den Rand der Verzweiflung. Es vergeht keine Woche, wo ich nicht mit dem Support schreibe. Nur leider komme ich keinen Millimeter weiter. Auf der Suche nach einer Alternative habe ich den libmbus von rscada http://www.rscada.se/libmbus/ gefunden und auf einem raspberry pi installiert. Damit ist es mir nun am letzten Wochenende gelungen die M-Bus Zähler auszulesen und die ausgelesenen Werte Variablen zuzuordnen. Und das alles mit NodeRed. :P

Diese Werte jetzt in Modbus Register zu schreiben sollte wohl auch möglich sein. Damit könnte das W-Gateway sogar ganz entfallen.

Kann ich die libmbus libary von rscada auch problemlos auf dem RevPiCore3 installieren?
Habt ihr damit schon Erfahrungen gemacht?

Ich möchte lieber im Vorfeld fragen, bevor ich mir das bisher Erreichte wieder mit einer Installation kaputt mache. Eine Sicherungskopie der SD-Karte werde ich vor der Installation sowieso machen, dass ist klar.

Ich möchte mich nochmals für den außergewöhnlich guten Support bei dir bedanken. Ich habe ja nun den dierekten Vergleich mit der Fa. Wachendorff. Euren Support würde ich mit 50 Sternen statt den sonst üblichen 5 Sternen bewerten.

Welcher Support antwortet so oft und so ausführlich. Ausgedruckt hat dein letzter Post neun DIN A4 Seiten ergeben. Auch daran erkennt man ganz deutlich, dass ihr voll hinter eurem Produkt steht. Tolle Sache.

Gruß Dieter
User avatar
volker
Posts: 1046
Joined: 09 Nov 2016, 15:41
Answers: 1

Re: RevPi Messwertwandler: TCPModbus Slave & Master

Post by volker »

Hallo Dieter,
vielen Dank für das Lob!
Mit unserem Projekt wollen wir ja gerade erreichen, dass die Kunden nicht auf von uns vorgegebene Wege gezwungen werden, sondern ihre eigene Kreativität und das eigene Vorwissen mit einbringen können. Daher war der von mir skizzierte Weg nur ein Vorschlag, wie ich selber sehr schnell zum Ziel kommen könnte. Aber wenn Du lieber den Weg über Node Red gehen willst, dann ist das sicher auch ein gangbarer Weg. Allerdings gibt es vom RevolutionPi Team bislang für die Anbindung vom Prozessabbild an Node Red noch keine Konten, die Du einfach installieren könntest und sogar mit PiCtory konfigurieren könntest. Wir sind an diesem Thema dran, aber das wird sicher noch einige Mponate dauern, bis wir da eine richtig einfache und gute Lösung präsentieren.
In der Zwischenzeit bist Du darauf angewiesen, Dir die Knoten selber zu schreiben (python, java) oder auf unserer Community zurückzugreifen. U.a. hat Boris von erminas Knoten geschrieben, mit denen Du auf das Prozessabbild zugreifen kannst. Dann würdest Du Modbus master und Slave genau wie in meinem langen Beitrag beschrieben unter PiCtory als virtuelles Modul konfigurieren und im Web-Status vom Device diese beiden Dienste aktivieren. Der Node würde dann auf das Prozessabbild zugreifen und sich dort die zyklisch abgelieferten Daten holen oder sie dorthin schreiben. Den Datenflow und die Vorverarbeitung könntest Du dann unter Node Red machen.
Alternativ kann man eventuell auch die direkte Modbus-Fähigkeit von Node Red nutzen, aber dazu kann Dich überhaupt nichts sagen - außer dass dann eben NICHT unsere virtuellen Module verwendet werden und die Daten dann auch nicht im zentralen Prozessabbild stehen. Somit sind dann auch alle anderen Produkte, die eventuell auf die Daten zugreifen wollen (HMI, Cloudanbindungen) außen vor (oder man muss für die dann konsequent auch wieder Nodes schreiben). Wir vom revPi Team sehen daher erhebliche Vorteile in der Vorgehensweise, unser zentrales Prozessabbild als Dreh- und Angelscheibe für den zyklischen Datenaustausch zwischen allen Komponenten des Systems zu sehen. Wenn Du zum Beispiel später dann mal unsere mBus-Produkte einsetzen willst (ja, die sind aktuell in Planung), dann brauchst Du keine neuen Nodes oder Treiber, sondern bekommst Die Daten so wie alle anderen (DIO, AIO, Modbus, etc.) über eine einheitliche Shcnittstelle vom zentralen Prozessabbild bereitgestellt.
Ob mlib problemlos installiert werden kann und läuft, weiß ich nicht. Ich empfehle Dir daher dringend einfach vor solchen Schritten eine Kopie vom Image zu ziehen, auf die Du ggf. das System wieder zurückbringen kannst. Dann wäre auch Dein Problem mit dem grauen Bildschirm wahrscheinlich gelöst worden. Ich gehe davon aus, dass du Dir da irgendwie Pakete teilweise so zerschossen hast, dass sie nicht mehr installiert waren. Dann nutzt natürlich ein apt-get upgrade auch nichts mehr, sondern die fehlenden Pakete müssen dann nachinstalliert werden. Aber das hast Du ja inzwischen selber rausgefunden.

Zu dem fehlenden Wiederanlauf virtuellen Modbus Modulen: Da haben wir inzwischen durch andere Rückmeldungen im englischen Forum erkannt, dass offenbar ein alter bekannter Bug sich wieder beim letzten Image eingeschlichen hat. Leider habe ich beim Testen einen anderen Softwarestand gehabt, so dass ich dieses Problem bei mir nicht nachvollziehen konnte. Deine Lösung ein piTest -x automatisiert durchführen zu lassen ist ein schönes "work around" für diesen Bug aber wir werden das natürlich umgehend bereinigen und korrigierte Pakete hochladen.

Zu mBus: Wir werden in wenigen Wochen an der SPS/Drives in Nürnberg unseren neuen RevPi Connect vorstellen. das ist eine Variante des Core, die speziell für Gateway Aufgaben konstruiert wurde. Ein der ersten Zusatzmodule für diesen neuen RevPi Connect wird ein mBus Modul sein (drahtgebunden und wireless). Plan ist, dies noch im ersten Quartal 2018 in Serie liefern zu können. Mit welcher Library wir dann dieses Produkt standardmäßig ausliefern werden, ist noch nicht entschieden. Die meisten Kunden werden aber direkt auf die interne SPI-Schnittstelle des mBus Chips zugreifen und sich eigene Software/Libraries dafür schreiben oder beliebige vorhandene damit ausprobieren. Wir werden dann lediglich eine Schiene daraus als Vorschlag und für Kunden, die nicht selber programmieren wollen, mitliefern. Diese Schiene wird dann aber sehr wahrscheinlich die daten über unser zentrales PA austauschen.

Soweit die Infos. Ich hoffe Du wirst mit der Node red Anbindung an das PA klarkommen (such mal nach den Forumsbeiträgen von Boris, er hat dazu schon mal was geschrieben und würde Dir sicher auch seine Nodes zur Verfügung stellen).

Gruß,
Volker.
Unser RevPi Motto: Don't just claim it - make it!
User avatar
volker
Posts: 1046
Joined: 09 Nov 2016, 15:41
Answers: 1

Re: RevPi Messwertwandler: TCPModbus Slave & Master

Post by volker »

Hallo,
wie Du vielleicht in "Neuigkeiten und Ankündigungen" gelesen hast, war tatsächlich ein bekannter Fehler immer noch im Modbus-Paket. Durch diesen Fehler läuft der Slave nach einem Reset nicht automatisch an. Der Fehler ist nun aber definitiv raus und ein apt-get upgrade sollte die Dinge endgültig bereinigen.
Unser RevPi Motto: Don't just claim it - make it!
Post Reply