Registerverschiebung

[RamiGspo]

Hallo Sebastian,

wir werden das Problem noch genauer untersuchen und wir werden dir eine Rückmeldung geben sobald wir mehr wissen.

[Draygoon]

Hi,
heute morgen habe ich das uns älteste verfügbare BusterImage vom 02.12.2021 auf einen weiteren RevPI aufgespielt und diesen (getrennt vom Internet) minimal konfiguriert. Es wurden von mir keine Updates oder Upgrades gefahren. Das Ergebnis ist das Selbe wie mit einem aktuell gehaltenem RevPI.
Pictory Version ist 2.0.4
2021-12-02-raspios-buster-armhf.img
keinerlei Updates/Upgrades



QModMaster mit passendem Stick zeigt beim Gerät nach wie vor Werte unter den regulären Registeradressen an. Das für mich Eigenartige ist, dass es um April herum bereits funktioniert hatte.

Edit: Jetzt habe ich alle Verbindungen getrennt - abgesehen vom RJ45-Kabel fürs Terminal. Der Modbus fährt normal hoch (was er eigentlich nicht dürfte) und gibt die Selben Werte aus.

[RamiGspo]

Hallo Sebastian,

Danke für deine letzte Post... dein Bild hat schon einiges erklärt.

Ich habe das Problem in die letzten Tage angeschaut und nachdem ich einiges simuliert habe, konnte ich dein Problem nicht reproduzieren.
Für meine Simulation habe ich mehrere Software verwendet, wie zum Beispiel "ModRSsim" oder "pyModSlave", aber wie gesagt, ich konnte mit keinem von denen das Problem reproduzieren.

Jetzt mit deinem Screenshot sehe ich, dass du auf die Adresse "4352" zugreifen wolltest:
"piTest -r 4352,5"
Die Addresse 4352 ist die RegisterAddress in dein Slave...

Um den Wert dieser Adresse sehen zu können kannst du eine Variable verwenden.
Die Modbusbefehle können eingestellt werden, und in "Device Value" musst du eine Variable eingeben.

PictoryConfig.png (16.06 KiB) Viewed 11915 times

Diese Variable kannst du mit piTest lesen.

Auf dem Bild sieht man die Variablen w1, w2 und w3, und die können mit piTest gelesen werden:

piTest -r w1
piTest -r w2
piTest -r w3

Schreiben wird in dem Fall mit ow1 gemacht:
piTest -w ow1,1

[Draygoon]

Sorry, war eine Woche krank.

Ja, genau diese Registerabfragen habe ich durchgeführt (wie man mehr oder weniger) auf dem Screenshot sehen kann.
Gibt es für mich eine Möglichkeit herauszufinden, ob der Modbus physikalisch beschädigt ist?
Wie kann es sein, dass der Modbus bei einer RTU-Abfrage sowohl beim Action_Status als auch beim Master_Status keine Fehler anzeigt, obwohl gar keine Verbindung besteht (weil das Kabel abgezogen ist)?
Und nachrangig: Wieso erhalte ich noch Registerwerte bis zum relevanten Bereich, auch wenn diese völlig falsch sind?

Danke!

[Draygoon]

Hi,

im Emailverkehr mit dem Support bekam ich eine Checkliste für den Modbus: https://kunbus-gmbh.atlassian.net/servi ... 2617212996

Diese Checkliste kann ich nicht vollständig durchführen: Wenn ich den Reboot per Terminal durchführe startet der RevPI zwar, aber nicht mit der Startkonfiguration die ich soeben eingegeben habe (sondern eine vom Mai 2022). Die config.rsc, die sich unter /etc/revpi/ befindet und auf /var/www/pictory/projects/_config.rsc verweist wird mit dem aktuellen Datum und der aktuellen Zeit der Änderung passend geschrieben, beim Neustart aber auf Mai 2022 zurückgesetzt.

Ideen?
Danke!

[Draygoon]

Also,
wir haben das Zielgerät erneut ausgetauscht (diesmal fabrikneu) und haben nach wie vor keine ModbusRTU-Verbindung mit dem Selben Fehler (110). Der Modbus selbst funktioniert aber, da ich lokal ein anderes Gerät (ein EM500) abfragen kann. Die Logik sagt, dass es am Zielgerät liegt, aber wir können mit dem QModMaster-USBstick normal die Daten abfragen - bis zum RevPI. Die Daten zur Kommunikation stimmen und sind mit dem QModbusMaster identisch.

Den Neustsart (und damit das Laden der fehlerhaften Konfiguration in Pictory) kann ich mit folgenden Terminalbefehlen vermeiden:
systemctl daemon-reload
systemctl restart pimodbus-master.service

Damit funktioniert der ModbusRTU für das alternative Gerät, aber am Zielgerät erhalte ich immer noch 0000 auf allen abgefragten Registerwerten.

[Draygoon]

Hallo,
Ich weiß jetzt woher die fehlerhafte Pictory-Konfiguration kommt:
-> einen 2. RevPI vollständig neu aufgebaut
-> Codesys (ohne Codesys-Lizenz) konfiguriert
-> unser Projekt geladen und die Ausführung probiert (was natürlich ohne Lizenzdaten für MC nicht funktioniert)

Das Ergebnis direkt nach dem Ausführungsversuch: Die Pictory-Konfiguration wurde auf CON CAN statt wie vorher (ohne Codesys) ModbusRTU/TCP-Master umgestellt und die Treiber wurden automatisch resettet.
Unser Projekt enthält sowohl eine CON CAN-Konfig als auch diverse Modbus Master RTU und TCP. Erstaunlicherweise wird nur ein CON CAN-Modul erstellt, nicht aber die ModbusMaster.

Also liegt dieses Problem bei Codesys! Edit: Und zwar in den Codesys-Dateien, die auf dem RevPI gepseichert werden.
Hat jemand eine Idee wie ich die ModbusMaster trotzdem zum Laufen bekomme?
Dankeschön!

[nicolaiB]

Hallo Sebastian,

verstehe ich dich richtig, dass du sowohl in CODESYS als auch Pictory den RevPi parametrieren möchtest?

Nicolai

[Draygoon]

Hallo Nikolai,

das Pictory verwende ich um herauszufinden, ob der RevPI überhaupt eine Datenverbindung zu den Zielgeräten aufbauen kann - völlig unabhängig von Codesys. Das funktioniert bis ich die 4.0.1.0 Runtime von Codesys auf dem RevPI installiere (über Codesys). Danach ist das Verhalten des RevPI eher komisch: Unser Projekt umfasst mehrere Modbus RTU-Master, die verschiedene Geräte abfragen, einen ModbusTCP-Master der ein bestimmtes Gerät steuert, einen ModbusTCP-Slave, von dem Werte ausgelesen werden und einen CAN-Slave, von dem ebenfalls Werte abgefragt werden. Wenn ich diese Codesys-Konfig auf den RevPI über die Runtime aufspiele und im Anschluss daran Pictory starte wird nur das CONCAN-Modul angezeigt. Die verschiedenen Modbusse werden (auch) über "piTest -d" nicht dargestellt.
Nach meinem Verständnis sollten aber die Modbusse ebenfalls angezeigt werden - oder liege ich da falsch? (Die Modbusse funktionieren über Codesys nicht!)

Für die Codesys-Konfiguration einer komplexeren SPS muss ich natürlich die Konfiguration des Pictory entfernen, damit es nicht zu Konflikten kommt. Umgekehrt das Selbe.

[nicolaiB]

Hallo Sebastian,

das Verhalten ist so gewollt. Sobald CODESYS verwendet wird, wird die Konfiguration (config.rsc) durch CODESYS geschrieben und die eventuell existierende Konfiguration überschrieben. Daher sind dann auch deine Modbus Master/Slaves weg. Die virtuellen RevPi Modbus Master/Slaves kannst du in CODESYS nutzen, sondern musst die Modbus Funktionen nehmen, die CODESYS bereit stellt. Der Gedanke hinter diesem Ansatz ist, das sämtliche Parametrierung und Konfiguration im CODESYS erfolgt.

Gruß Nicolai