Nodes bleiben im Conneting hängen

ghx · Post by **ghx** » 19 Oct 2024, 20:28

Hallo zusammen,

bisher konnte ich über die Revpi-Nodes ohne Probleme auf In- und Outputs zugreifen. Nun wollte ich noch Modbus RTU-Sensoren über Pictory mit einbinden. Seit dem funktioniert es nicht mehr...

Was hab ich geändert: Der Modbus-Master war bisher in Pictory bereits konfiguriert aber noch ohne "Erweiterte Daten" in Betrieb. Nun habe ich dort einen Datensatz eingefügt, gespeichert und die Treiber zurückgesetzt. Seit dem bleiben alle Nodes auf "Connecting..." stehen. Mit Ausnahme der Core-Inputs (Core-Frequency, Core-Temp), die einwandfrei laufen.

Ich habe testweise das Hardwaresetup in Pictory neu aufgesetzt und mit wenigen Nodes getestet. Ohne Erfolg. Selbstverständlich wurde auch ein Systemreset getestet. Auch ohne Erfolg.

Hier mal die letzten Zeilen des cat /usr/share/noderedrevpinodes-server/revpi-server.log

Code: Select all

2024-10-19 20:09:24,407 root        : INFO     New client connected and was given id a2cb85dc-c101-4250-aef2-d64a3ff96052
2024-10-19 20:09:24,410 root        : INFO     User is authorized
2024-10-19 20:09:24,524 root        : ERROR    Connection to websocket client a2cb85dc-c101-4250-aef2-d64a3ff96052 closed unexpected: WebSocket connection is closed: code = 1005 (no status code [internal]), no reason
2024-10-19 20:09:24,526 websockets.server: ERROR    Error in connection handler
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/websockets/server.py", line 169, in handler
    yield from self.ws_handler(self, path)
  File "revpi-server.py", line 458, in handle_clients
    await t
  File "revpi-server.py", line 427, in get_client_requests
    raise e
  File "revpi-server.py", line 319, in get_client_requests
    message = await client.websocket.recv()
  File "/usr/lib/python3/dist-packages/websockets/protocol.py", line 434, in recv
    yield from self.ensure_open()
  File "/usr/lib/python3/dist-packages/websockets/protocol.py", line 658, in ensure_open
    ) from self.transfer_data_exc
websockets.exceptions.ConnectionClosed: WebSocket connection is closed: code = 1005 (no status code [internal]), no reason

Post by **dirk** » 21 Oct 2024, 09:11

Hi ghx, kannst du uns einen SOS-Report zukommen lassen?
https://kunbus-gmbh.atlassian.net/servi ... 2036400208

Danke für die gute Darstellung des Fehlerbildes und der Schritte, die Du bereits getan hast, um das Problem in den Griff zu bekommen.

Der RevPi-Way geht immer über das Prozessabbild, was die Problematik handlich macht, weil zerlegbar in Einzelteile.

1) Thema Daten per Modbus-RTU vom Sensor ins Prozessabbild bekommen
2) Danach wie komme ich dann die Daten z.B. per RevPi-Nodes-Server ran

Also bleiben wir bei 1) mit SOS-Report kann ich "dein" System erst einmal umfassend einsehen, aber auch vorher kannst du schon hier beginnen:

RS-485 Checklist
Modbus Checklist
Modbus RTU Communication

Wenn diese Dinge stehen und die Daten so wie im Video Tutorial z.B. per "piTest -r Input_1" zu sehen sind dann würde ich weiter gehen zu 2)

ghx · Post by **ghx** » 21 Oct 2024, 16:56

Hallo Dirk,

SOS-Report ging an die Support-Email.

Das Problem liegt ja nicht ausschließlich beim Modbus. Ich kann auch die Daten von DIO und MIO-Modulen nicht mehr lesen/schreiben.

Per modpoll kann ich die Modbus-Hardware einwandfrei bedienen.

Code: Select all

modpoll -p none -1 -b 19200 -a 11 -r 2 -c 1 /dev/ttyUSB1

liefert einwanfrei Messwerte.

Gruß
Hermi

Post by **dirk** » 22 Oct 2024, 10:05

Hallo, danke für den SOS-Report, den ich soeben mit dem RevPi SOS-Parser analysisert habe. Das hilft mir in die Mitte der Sache zu kommen und konstruktiv zu helfen, klasse:
Es gibt Fehler auf der PiBridge Kommunikation. Die Lösung hierfür ist, die beiden MIO Module zu aktualisieren:
https://revolutionpi.com/en/tutorials/i ... are-update
Hier auch eine Übersicht der Firmware-Stände pro Modul:
https://gitlab.com/revolutionpi/revpi-firmware

Dann verwendest du noch RevPi Buster OS mit Kernel 5.10 → bitte aktualisiere dein System mithilfe der Schritte dieser Checkliste zumindest auf Bullseye 64 Bit, denn der 32 Bit Support wird alsbald eingestellt:

https://kunbus-gmbh.atlassian.net/servi ... /836468748

ghx · Post by **ghx** » 22 Oct 2024, 18:24

Hallo,

mit dem alten Image wollte kein Firmware-Update der MIOs funktionieren.
Also neues Image...
Dann Firmware-Update nach Anleitung über piTest -f Immer mit der Meldung

Code: Select all

update firmware success

.
Aber ein MIO ist jetzt scheinbar gebrickt. Alle Module hinter dem MIO sind nicht mehr sichtbar.

das gebrickte MIO Steckt auf dem 2 Platz nach dem Core

Code: Select all

Found 7 devices:

Address: 0 module type: 95 (0x5f) RevPi Core V1.2
Module is present
     input offset: 0 length: 6
    output offset: 6 length: 5

Address: 32 module type: 118 (0x76) RevPi MIO V1.2
Module is present, but NOT CONFIGURED!!!
     input offset: 11 length: 34
    output offset: 45 length: 27

Address: 33 module type: 32886 (0x8076) RevPi MIO V0.0
Module is NOT present, data is NOT available!!!
     input offset: 11 length: 34
    output offset: 45 length: 27
    
Address: 34 module type: 32864 (0x8060) RevPi DIO V0.0
Module is NOT present, data is NOT available!!!
     input offset: 241 length: 70
    output offset: 311 length: 18

Address: 35 module type: 32864 (0x8060) RevPi DIO V0.0
Module is NOT present, data is NOT available!!!
     input offset: 354 length: 70
    output offset: 424 length: 18

Address: 36 module type: 32864 (0x8060) RevPi DIO V0.0
Module is NOT present, data is NOT available!!!
     input offset: 467 length: 70
    output offset: 537 length: 18

Wenn ich die beiden MIOs tausche, wird eben keines mehr erkannt.
Ein Firmware-Update will auch nicht funktionieren:

Code: Select all

Virtual modules don't have firmware to update

und nun???? MIO defekt? Oder gibt es noch eine Möglichkeit?

ghx · Post by **ghx** » 24 Oct 2024, 12:41

Hallo Dirk,

was kann ich jetzt mit dem zurprogrammierten MIO machen.Oder hab ich jetzt Edelschrott???

Post by **dirk** » 04 Nov 2024, 12:16

Hallo ghx, ich bin bestürzt zu hören, dass das RevPi MIO Modul nicht mehr ansprechbar ist nach dem Firmware-Update. Bitte wende dich an deinen Händler und leite dort diesen Servicefall ein. Wenn du das Modul direkt bei KUNBUS gekauft hast, schicke uns eine E-Mail an support@kunbus.com mit Details zum Kauf und den Daten des Data Matrix Codes auf der Frontseite.