Kommunikation zwischen RevPi Core als Modbus-TCP-Master/Slave (Jessie)

[Martin]

Guten Tag Volker, (nochmal, ich habe wahrscheinlich schon mal was versehentlich gesendet, bin leider noch nicht mit den Thema Foren so vertraut)
Ich habe ein kleines Projekt mit RevPi Core-Module zu realisieren. Die eigentlichen Funktionen auf den einzelnen Stationen laufen schon. Das habe ich (als gelegentlicher S5/7-User) relativ schnell mit Herrn Huber und Herrn Zögernitz von logicals zum laufen gebracht.
Nun müssen "eigentlich nur" die RevPi Core-Module untereinander Daten austauschen (1 Wort reicht völlig aus, es handelt sich nur um Signale zur gegenseitigen Verriegelungen, Lebensbit o.ä.) Beim Mitwettbewerber nennt man das Querkommunikation, was es auch in Prinzip ganz gut im ganzen beschreibt. Diese Querkommunikation wollte ich mit der Onboard Modbus TCP-Fähigkeit unter Jessie realisieren, soweit der Plan. Logicals hat mir auch vorgeschlagen das man das mit MQTT bewerkstelligen könnte, das erscheint mir aber nicht sinnvoll weil man dazu ein übergeordneten Broker braucht und die Modbus Sachen ja auch besser in die SPS-Welt passt. Die Tutorial von Dirk habe ich schon weitestgehend erfolgreich durchgearbeitet, alles sehr schön soweit. Nun fehlt mir nur ein Beispiel wie ein RevPi Core-Module als Master mit ein RevPi Core-Module als Slave z.B. ein Wort austauscht, bzw. wie soll ich die FDB-Bausteine der LibModbus von logicals aufrufen muss um das Wort vom Slave zum Master zu bekommen. Bzw. ob diese Bausteine überhaupt mit Jessie laufen/nötig sind weil diese ja wohl auch für die Hardware Gateways sind oder?
In den Release Notes Jessie_DE werden diese Funktionen zu mindestens so dargestellt. Oder sehe ich das alles zu kompliziert und man mach so was ganz anders, weil ja SPS und SPS vom selben Hersteller ja sich eigentlich so zusagen Plug and Play verstehen müssten oder?

m.f.g. Martin

[volker]

Hallo Martin,
ob und wie Du so etwas mit logi.cals Modbus-Bausteinen verwirklichen kannst, weiß ich nicht, da muss Dir der logi.cals support evtl. weiterhelfen. Aber generell haben wir von Revolution Pi dafür eigentlich eine andere Lösung, die unabhängig von logi.cals läuft und die ich in diesem Fall immer bevorzugen würde. Unsere Modbus-Master und Slave-Module arbeiten ja ganz ohne Fremdsoftware unabhängig auf dem RevPi Core, wenn Du sie a) aktivierst (im Wbe-Setup unter Dienste) und b) in PiCtory als virtuelles Modul einbindest und konfigurierst. Wie man da macht, wird in den Tutorials eigentlich sehr detailliert beschrieben. Im Prinzip sagts Du dem Master-Modul, welche "tasks" es zyklisch ausführen soll. Das geht über das Kontextmenü vom Modul als "extended Data". Dort würdest Du eben nur eine Task definieren, die einen einzige Zugriff "read egister" oder "write register" auf den slave macht und das Ergebnis (1 word) in das ensprechende Input oder output word des moduls legt (als wäre es ein physikalischer input oder output von einem AIO oder DIO). Die Daten liegen dann im zenralen Prozessabbild und wenn Du das Häkchen für Export setzt, dann stehen si Dir auch unter LC3 zur Weiterverarbeitung zur Verfügung. Beim Slave ist es noch einfacher, dort ist es einfach so, dass 32 Register und 32 Coils jeweils für input und output bereitstehen, die von einem Master abgefragt werden können. Die Registeradressen beginne bei 1 und Du kannst über die Registeradresse damit enscheiden, in welchen der bereitgestellten Eingänge vom Master geschrieben wird oder aus welchen Ausgängen vom Master gelesen wird. Diese Ein- und Ausgänge sind ebenfalls ganz normale Ein- und Ausgänge vom Prozessabbild und können daher genauso über den Exporthaken LC3 bereitgestellt werden.
Natürlich müssen die Basisdaten für Master und slave (IP-Adresse, Port) korrekt konfiguriert sein.
Fang einfach mal damit an und frag dann konkrete Dinge, wenn Du wo hängen bleibst (am besten mit screen dump).
Viel Erfolg.

[Martin]

Danke für die schnelle Info, diese Vorgehensweise habe ich zwar verstanden aber mir war nicht klar dass das wirklich ohne irgendwelche Aufrufe in LC3 klappt, dann teste ich das mal so, mit den PC Simulatoren habe ich ja schon mal was hinbekommen. Gut, dann ist ja das WE gerettet.

Gruß Martin

[volker]

Na dann ein erholsames WE

[Martin]

Hallo Volker,
ich habe die Kommunikation im Büro erfolgreich testen können, gute Sache soweit. Nun habe ich wie folgt die folgenden Konfigurationen, in mühevoller Kleinstarbeit vor Ort in den 34 Steuerungen eingetippt (man kann das ja leider nicht kopieren oder?) und hatte natürlich kein Erfolg. Im Folgenden kurz mal notiert was ich so wollte.

Pos 64 Slave soll 1 Wort von Steuerung 192.168.101.133 schreiben
Pos 65 Master 1 soll 1 Wort von Steuerung 192.168.101.132 lesen (Satus von der Vorgänger Anlage)
Pos 66 Master 2 soll 1 Wort von Steuerung 192.168.101.134 lesen (Satus von der Nachfolger Anlage)

Ich habe da wohl irgend ein Eintrag nicht ganz richtig, kannst du das mal überfliegen, ich tippe da total im dunklen.
Hier noch einige Bilder, hoffe dass du das so schnell nachvollziehen kannst.
Und hier noch die Adressen:
Output_1 AT %QW1.188: WORD := 0; //
Input_Word_1 AT %IW1.255: WORD := 0; //
Action_Status_Reset_2 AT %QX1.424.1: BOOL := 0; //
slave_IP_address AT %M1.429: STRING := '192.168.101.132'; //
slave_TCP_port AT %MW1.445: WORD := 502; //
Input_Word_1_i06 AT %IW1.447: WORD := 0; //
Action_Status_Reset_1_i06 AT %QX1.616.0: BOOL := 0; //
slave_IP_address_i06 AT %M1.621: STRING := '192.168.101.134'; //
slave_TCP_port_i06 AT %MW1.637: WORD := 502; //

Hardware.png (239.34 KiB) Viewed 9121 times

Master1.png (176.47 KiB) Viewed 9121 times

Master2.png (118.35 KiB) Viewed 9121 times

Gruß Martin

[volker]

Unter der Annahme, dass die IP von dem System, welches Du hier abgebildet hast die 192.168.101.133 ist, hast Du prinzipiell alles richtig gemacht. Was bedeutet denn genau, dass "kein Erfolg"? Wie prüfst Du das?
hast Du unter "Dienste" im Webstatus des Geräts bei allen beteiligten Geräten den Modbus-Server UND Modbus Slave Dienst eingeschaltet?
Am einfachsten ist die Prüfung dann über einen SSH-Zugriff auf alle beteiligten Systeme: Du machst auf das Register 1 eines RevPi einen write mit PiTest, etwa so:
piTest -w Output_1,12345
Dann machst Du bei dem Vor- und Nachgängergerät jeweils einen read mit piTest:
piTest -r Input_Word_1
bzw.
piTest -r Input_Word_1_i06

Diese beiden reads sollten dann als Ergebnis "12345", also den Wert aus dem mittleren Core im Modbusregister 1 ergeben. Ist dies nicht der Fall, dann musst Du mal das Statusbyte vom Slave bzw. das ActionStatusbyte 1 vom Master anschauen, ob das ein Fehler drinnen steht.

Zum Verteilen von Konfigurationen auf mehrere Geräte:
Die Konfiguration steht ja nach dem Speichern in einem File _config.rsc. Diesen kannst Du kopieren. Natürlich musst Du dann aber die IP Adressen anpassen...

[Martin]

Hallo Volker,
ja gut oder auch nicht gut, ich hoffte das ich irgendwo ein Fehler gemacht hätte. Mit "kein Erfolg" meinte ich das ich ein Wert im Slave geschrieben habe aber beim Master kam nichts an bzw. 0000. das habe ich alles im LC3 kurz getestet. Kannst du mir denn die möglichen Fehler von den Statusbytes geben, dann komme ich eventuell alleine etwas weiter. Bei meinen Test im Büro war 00 und 0D i.O und 6E bei gezogenem RJ54-Stecker. Die Dienste habe ich natürlich auch aktiviert aber ich prüfe das auch noch mal.
Gut dann teste ich das mal mit SSH, eventuell kommt das in LC3 nicht richtig an oder ich überschreibe da irgendwas, bin leider auch noch nicht so fit in LC3 mit Querverweise usw..
Gruß Martin

[volker]

Mach das bitte immer erst mit piTest, um alle anderen Fehlerquellen auszuschließen. Die Fehlercodes sind im Tutorial zu finden:
https://revolution.kunbus.de/tutorials/ ... verwenden/
Sie sollten immer 0 sein, wenn das System korrekt aufgebaut ist und Daten austauscht, sowohl der "Modbus_Master_Status" als auch alle vorhandenen Status zu den Modbus-Aufgaben aus der "extended data" Liste ("Modbus_Action_Status_[1 … 32]“). Letzterer enthält die Status codes, so wie im Modbus Standard definiert.

[Martin]

Hallo Volker,
ich habe das jetzt noch mal in Ruhe mit SSH/piTest getestet und siehe da es geht wie versprochen, aber sobald ich logi.RTS im Slave aktiviere wird in Output_1 irgendwie 0000 überschrieben, obwohl ich den in der Variablentabelle auf 1111 gesetzt habe. Ist das jetzt ein Fall für logi.cals oder hast du noch eine Idee? Oder habe ich da was mit der Symbolik/GLOBALS hardwareConfig falsch gemacht?
Zweite Sache, wo finde ich die _config.rsc? Kann ich die mit Filezilla kopieren?
Gruß Martin

[volker]

Hi,
da hast Du sehr wahrscheinlich einen "Knoten" reingebastelt. Mit Deinen Angaben kann ich leider nicht komplett nachvollziehen, welche Werte Du in LC3 dann eigentlich importierst und liest oder beschreibst. Die Symptome deuten aber sehr stark darauf hin, dass Du etwas versuchst, was rein prinzipiell nicht möglich ist:
Ein Ausgang kann immer nur von einer Quelle gespeist werden. In LC3 werden Ausgänge beschrieben, d.h. LC3 wird zur Quelle und beschreibt zyklisch die Ausgänge (ggf. mit dem Default 0).

Die Bezeichnungen "Ausgang" und "Eingang" sind immer relativ zur Steuerung (RevPi!) gesehen.

Werte, die von außen reinkommen sind "Eingänge". PiControl list die Eingänge zyklisch und schriebt die Werte ins Prozessabbild. Dort können sie von vielen Zielprogrammen (u.a. LC3) parallel ausgelesen werden. Beschreiben sollte man sie mit LC3 besser nicht, denn piControl wird sie zyklisch mit den von außen eingelesenen Werten beschreiben.

Werte, die nach außen gesendet werden sind "Ausgänge". Sie zu lesen macht meist wenig Sinn. Sie werden zyklisch von PiControl mit dem Inhalt des Prozessabbildes beschrieben. Daher sollte eigentlich möglichst nur 1 Quelle diese Offsets im Prozessabbild beschreiben.

Der Modbus Master verwendet die Begriffe sehr logisch aus Sicht der Steuerung. Ausgänge vom Master sind Werte, die nach außen gehen und beim Slave in der Regel echte Ausgänge schalten. Eingänge vom Master sind Werte, die vom Slave gelesen werden und entsprechen oft echten Schalteingängen, die am Slave angeschlossen sind.

Beim Modbus Slave ist das alles ein wenig verwirrend: Die Bezeichnungen "Ausgang" und "Eingang" sind hier praktisch verdreht: Die Eingänge sind nicht etwa "Eingänge" im Sinne von Modbus (also Werte, die von IOs kommen und dem Master zum Lesen bereitgestellt werden), sondern es sind die Werte, die der Master an "Ausgänge" vom Slave sendet. Das kommt daher, dass diese Werte ja vom Master kommen (also von "außen" in den RevPi) und vom Slave in das Prozessabbild geschrieben werden (so als wären es irgendwelche Eingänge von Eingangsmodulen). Entsprechend sind die Ausgänge beim Slave Modul eben nicht die Modbus "Ausgänge", die ein Master beschreiben kann, sonder es sind die Modbus Eingänge, die der Master einlesen kann und die letztlich aus dem Prozessabbild vom RevPi kommen. Da sie aus Sicht des revPi nach "außen" gehen, sind es Ausgänge´, die zyklisch von PiControl und genau 1 Quelle (z.B. LC3) beschrieben werden. Ich vermute, Du wills so einen Slave Ausgang (also aus Modbus Master Sicht "Inputs") in LC3 lesen. Da wirst Du aber immer nur 0 lesen, wenn LC3 diesen Ausgang in seiner Deklaration stehen hat, weil dann LC3 zyklisch diesen Ausgang mit 0 beschreibt.

Deine Software (egal ob LC3 oder Python) muss die Slave Ausgänge zyklisch mit den Mastereingängen beschreiben und die Masterausgänge müssen zyklisch mit den Slaveeingängen beschrieben werden, damit die Werte in einer Kette durchgereicht werden. LC3 sollte die Ausgänge überhaupt sonst nicht anfassen, sondern nur Eingänge lesen und verarbeiten. Oder aber LC3 muss die Kopierarbeit übernehmen und die Werte so wie eben beschrieben zyklisch kopieren.

Ist ein wenig eine Kopfnuss, aber wenn Du es mal gründlich durchdenkst und auf einem Stück Papier aufmalst, ist es eigentlich ganz logisch. Solltest Du da trotzdem Hilfe brauchen, dann maile bitte mal sehr genau mit Beispiel, was Du von wo nach wo senden willst und welche Komponenten da in der Software wo eingreifen sollen...