Modbus-Kommunikation bricht ab

[ghx]

Hallo,

Ich habe nach einigen Anfangsschwirigkeiten Modbus unter RevPi am laufen. Leider bricht nach einiger Zeit die Kommunikation ab.

Zum Aufbau:
Revpi Core S mit Waveshare USB-Modbus-RTU
Modbushardware mit 16 Analogeingängen
Pictory Modbus RTU-Master eingestellt mit 16 ActionIDs auf die 16 Lese-Register (FunctionCode 3)

Nach einem Rechnerneustart läuft alles wie es soll. Aber nach einigen Stunden werden keine Daten mehr empfangen.
Lesen über piTest liefert immer die alten Messwerte.
piTest -1 -r Modbus_Action_Status_1;piTest -1 -r Modbus_Master_Status liefert:

Code: Select all

1 Byte-Value of Modbus_Action_Status_1: 0 dez (=00 hex)
1 Byte-Value of Modbus_Master_Status: 0 dez (=00 hex)

Aber der Socket bleibt belegt. Ein erneutes Öffnen z.B. mit Modpoll zeigt einen socket open error!

Nun habe ich die Intervalzeit von 1000ms auf 10000ms erhöht. Aber die Zeit zwischen Start und Ausfall bleibt scheinbar gleich.

Leider läßt sich die Ausfallzeit nicht genau bestimmen, da einfach immer weiter die alten Werte zurückgegeben werden, bzw unter Node Red keine Änderung mehr kommt.

Der Ausfall läßt sich nicht über einen Treiber-Reset nicht beheben. Da wird nur Modbus_Master_Status: 255 dez ausgegeben.
Bis jetzt half nur Reboot

Wo liegt der Fehler?

[dirk]

Hallo, ghx klingt spannend, kannst du

• einen SOS-Report erstellen und
• eine Skizze vom Aufbau?
• Kannst du auch Oszilloskop Traces der RS485 Kommunikation machen?
• Wie sieht der Zugriff auf die RS485 Schnittstelle aus der Anwendung aus?
• Bitte befolge die Schritte dieser Checkliste: RS-485 Checklist
• Wie oft kommt der Fehler?
• Gibt es Dinge, die sich verändern?

Wenn du von Rechner Neustart sprichst weil modpoll noch einen offenen Prozess hat bedeutet das, dass dein PC als Modbus Client fungiert und das RevPi als Modbus Server?

[ghx]

Hallo Dirk,

SOS-Report ist schwirig. Der Fehler kommt immer im ungüstigsten Zeitpunkt. Da muss es schnell gehen. Ausserdem sind die Ausfallabstände länger geworden.

Hier das Blockschaltbild des Aufbaus.
Für den Trace muss ich mir noch ein Scope holen. Kommt die nächsten Tage.
Der Zugriff läuft über Node-Red revpi-single-inpute-Node. Da kommen dann keine neuen Werte mehr.
Die Kommunikation kann an den LEDs des USB/485-Wandlers und der Modbus-Karte mitverfolgt werden.
hier die Konfig des Virtuellen Modbus-Masters:

Die Ausfallabstände sind sehr unterschiedlich und irgendwie auch mit nix in Zusammenhang zu bringen. Anfangs zwischen 12 und 24h, dann, direkt auf diese Anfrage 7Tage, dann nur 5h, aktuell läuft es schon wieder einige Tage.
Die Ins und Outs der DIOs und MIOs funktionieren aber weiter.

Da ich einen 2. USB-485-Wandler habe, werde ich diesen jetzt mal als Sniffer an einen anderen Raspi mitlaufen lassen.

[ghx]

Jetzt war es wieder soweit...

Die Werte blieben einfach hängen und keine Kommunikation mehr auf dem Modbus. Der Sniffer brachte wenig Erkenntnis. Die Anfragen hören einfach auf. Die letzten empfangenen Werte passen zu den Werten, die ich im Revpi sehe.

Jetzt habe ich einen SOS-Report des Systems gemacht und durchgeschickt.

[ghx]

Noch zu der Frage mit Modpoll:
Modpoll läuft auf dem Revpi. Der PC hängt nur über Netzwerk dran. (und jetzt mal kurz über den Sniffer)

[dirk]

Hi ghx, auch für Deine Skizze des Aufbaus und für den SOS-Report, den ich per E-Mail erhalten hab und gerade bereits grob durchgeschaut. Du könntest die Kernelversion und Dein System an sich aktualisieren, mit

Code: Select all

sudo apt update
sudo apt upgrade

Die Firmware-Versionen der IO Module sind aktuell.

Was ich seltsam finde, ist, dass Dein Kern.log etwas kurz ist.

Danke auch für den Screenshot der Modbus Actions - da ist mir aufgefallen, dass Du das optimieren kannst:
(1) Zahl 16 Eintragen
(2) Selektieren
(3) Löschen

Kannst Du diese Änderung probieren und schauen, ob das Problem damit bereits erledigt ist?

[ghx]

Was ich seltsam finde, ist, dass Dein Kern.log etwas kurz ist.

heißt?

Danke auch für den Screenshot der Modbus Actions - da ist mir aufgefallen, dass Du das optimieren kannst:
(1) Zahl 16 Eintragen
(2) Selektieren
(3) Löschen

Kannst Du diese Änderung probieren und schauen, ob das Problem damit bereits erledigt ist?

Das hatte ich schon einmal probiert. Da bekomme ich immer nur das 1. Word zurück. An die anderen 15 komme ich nicht ran.
Als Testcase das hier aufgebaut:

Pictory Modbus-RTU-Master:

Node-Red-Testcase:

Die obere Leitung kommt von einem 10s Ticker

Debug Output der 3 Varianten:

Wenn ich das Object aus dem multiple-input auspacke kommt das raus:

Code: Select all

{"Input_Word_20":"192"}

Wie komme ich also an die anderen Registerwerte ran? Oder gibt es eine Möglichkeit, aus dem Word ein Multi-Word zu machen?

[ghx]

bin jetzt doch auch selbst drauf gekommen.
Die weiteren Werte tauchen auf den folgenden Input_Words auf.

Dann kann ich das mal probieren. Melde mich spätestens wieder, wenn es wieder ausfallen sollte...

[dirk]

Ja klassomato
Also ich denke, am einfachsten ist es, wenn du z.B. mit piTest auf der Shell die Modbus Werte prüfst bevor noch Nod-RED erschwerend hinzukommt.

Am einfachsten kannst du alle Werte auf einmal so abfragen:

Code: Select all

piTest -r <Offset,Länge,Format>

Den Offset kannst du so abfragen:

Code: Select all

piTest -v Input_Word_17 

[ghx]

geht piTest -r auch für WORD oder nur für BYTE?