The Industrial Raspberry Pi Forum

Guten Tag,
Ich bin grade dabei einen RevPi Connect 5 remote in Betrieb zu nehmen. Der RevPi sammelt Betriebsdaten einer Kunden PLC über das EtherNet/IP Gate und Codesys und schickt sie dann an einen Server weiter, wo sie dann Online einsehbar sind.
Nur kommt im Gate nichts an.
IP-Adresse des Gates wurde nach Anleitung eingestellt.
Systeminfo:
RevPi Connect 5 100412
Linux RevPi______ 6.6.0-revpi6-rpi-v8 #1+deb12+1 SMP PREEMPT_RT Wed, 27 Nov 2024 14:13:38 +0000 aarch64 GNU/Linux
Gate EtherNet/IP 100066
Codesys: 3.5.20.20 Firmware 4.13.0.0

Es gibt folgenden wiederkehrenden Logeintrag:
PiControl: pileft:received duplicate data packet
PiControl: pileft: received data packet ack 0x36, expected 0x37

Bei dem received data packet ist es immer um eins Kleiner als erwartet.

Hi Jannis,

dein System scheint noch auf einem sehr alten Softwarestand zu sein (der Kernel ist bald 1,5 Jahre alt). Bitte spiele die aktuellen Updates ein (z.B. via Cockpit) und versuche es noch einmal.

Gruß Nicolai

Guten Tag,
Ich habe jetzt die updates über Cockpit eingespielt. System ist up to Date. aber ich empfange weiterhin keine Daten von dem EtherNet IP Gateway.
Die Fehlermeldung lautet jetzt:
piControl: pileft: timeout

Kannst du uns bitte einen sos report an support@kunbus.com zu kommen lassen? Dann schauen wir ob es dort Auffälligkeiten gibt. Bitte nimm in der E-Mail Bezug auf diesen Forumspost. Danke!

Gruß Nicolai

Guten Tag,
Bis jetzt habe ich keine Antwort vom Support bekommen.
Ich habe jetzt nochmal einmal eine E-Mail an die angegebene Email geschrieben.
Bitte um Zeitnahe Rückmeldung

Die Email kommt bei euch nicht an, siehe screenshot

Hi Jannis,

ich gebe das Problem an unsere IT weiter. Alternativ kannst du den SOS Report auch auf einer Plattform deiner Wahl (Onedrive etc) hochladen und per Link in der der EMail mit uns teilen. Danke

Gruß Nicolai

Hallo Jannis,
wir haben dein sos-report bekommen, dankeschön.
Der sos-report ist von einem anderen Gerät (Connect4) auch mit einem alten Kernel:

Bei dem Gerät sieht es so aus: Wurde der Kernel geupdatet?



Aktuell sollte es so aussehen:

Ich hab jetzt nochmal nachgeguckt.
Der 1. Screenshot ist von Meshcentral unser Remote tool
Der zweite Screenshot von Cockpit
Der dritte der in Cockpit erstellte SOS-Report


Jetzt die alles entscheidende Frage: wieso sagt mir das System RevPi 5 und der SOS Report sagt RevPi 4?
(Ich habe auch bei uns so in die Excel Liste RevPi 5 eingetragen, die wir für alle Projekte führen. Dort stehen: RevPi Model, MAC-Adressen, Passwörter etc.)
Auch die Serial-Nummer ist eine andere.


Ich habe jetzt noch einen erstellt und per Mail zugeschickt

Hallo Jannis,

entschuldige bitte die lange Wartezeit. Ich habe dir die Auswertung eben per E-Mail geschickt, hier im Forum aber auch noch einmal, damit andere etwas davon haben.

Zu deiner Frage mit RevPi 5 und RevPi 4... der erste SOS-Report war einfach von einem anderen Gerät. Dort stand als Produkt ein Connect 4 mit der Seriennummer 157345, im zweiten Report steht der Connect 5 mit der Seriennummer 141980, und die passt zu dem, was Cockpit und Meshcentral bei dir anzeigen. Auch die Uptime von 27 Tagen in deinem Cockpit-Screenshot passt genau zum letzten Neustart in diesem Report. Der Report selbst liest Modell und Seriennummer direkt aus der EEPROM des Geräts, verwechseln kann er sie also nicht. Dass als Hostname host0 auftaucht, kommt nur von der Obfuskierung beim Erstellen des Reports, dabei werden Hostname, IP- und MAC-Adressen ersetzt.

Der zweite SOS-Report ist also vom richtigen Gerät und ich habe es angeschaut.
Ich denke, dass das Update vom 24.04. wurde mitten im Vorgang abgebrochen, dpkg ist seitdem in einem inkonsistenten Zustand und ein apt-get check meldet "dpkg was interrupted". Deshalb konnte danach kein Update mehr installiert werden, auch das über Cockpit nicht. Das Gerät läuft weiterhin mit dem Image 01/2025, Kernel 6.6.0 von November 2024 und piControl 2.3.1, obwohl Cockpit keine offenen Updates mehr anzeigt...

Du kannst folgendes ausprobieren:
Der erste Befehl läuft auch ohne Internetverbindung. Wichtig ist hier full-upgrade...
Danach kannst du prüfen, ob Kernel 6.12.x und piControl 2.6.x aktiv sind:
Unabhängig davon lief zum Zeitpunkt des Reports codesyscontrol nicht, es lief nur codesysedge.
Prüfe bitte, ob die Runtime läuft und ob die Applikation geladen und im Run-Zustand ist. Ohne laufende Runtime kommen keine Daten an, ganz unabhängig vom Gateway.
Ich denke, dass das Gateway gut aussieht. Es wird erkannt, Typ 75 mit Firmware V1.1, und ist mit 480 Byte Ein- und Ausgangsdaten präsent, die PiCtory-Konfiguration passt ebenfalls. Im letzten Bootvorgang, vom 29.05. bis zum Report am 02.06., gibt es keinen einzigen pileft-Fehler mehr. Die Meldungen mit den duplicate data packets und den Timeouts stammen aus dem April und traten immer zusammen mit kurzen Link-Abbrüchen auf der PiBridge auf.
Komisch finde ich, dass eth0 am 02.06. mehrfach den Link verloren hat, dort würde ich mir die Netzwerkseite mit Switch und Verkabelung ansehen.

Gib uns gerne Bescheid, ob das funktioniert hat. Falls danach noch etwas übrig bleibt, schick mir einfach einen neuen SOS-Report.