Prozessabbild Kommunikation gestört RevPiCompact

[Simvei001]

Hallo zusammen.
Wir haben den Revolution Pi Compact im Einsatz und nutzen über das Prozessabbild die Digitalen Ein- und Ausgänge.

Dafür haben wir einmalig (damals noch unter stretch) eine Pictory Konfiguration erstellt und diese für diverse Anlagen verwendet und immer diese eine Konfiguration auf neue Anlagen übertragen.

Nun haben wir mittlerweile auf das neuere Basis-Image (latest-revpi-bullseye-arm64-lite) geupdated.
2 Änderungen sind hier zu verzeichnen (armhf -> arm64 und stretch -> bullseye).

Der Anlagenbetrieb konnte erst wie erwartet gestartet werden und auch die Kommunikation zu den DIOs des RevPi Compact funktionierte nach der Konfiguration mit der erstellten Pictory Konfiguration wie erwartet.

Leider hat sich bei weiterem Betrieb der Anlage herausgestellt, dass ab irgendeinem Zeitpunkt die Synchronisation des Prozessabbildes mit den DIOs einstellt.

Fehlerzustand:
Zuletzt haben wir diesen Zustand erreicht, als ein Ausgang abfallen sollte (und dies auch tat), wir ein Rücksignal am Eingang aber weiterhin anliegen hatten, obwohl physikalisch kein Signal mehr vorlag.

Im folgenden haben wir zunächst versucht nur mit den `piTest` Kommandos Signale aus dem Prozessabbild zu lesen und zu schreiben, was auch weiterhin ohne Probleme funktioniert hat. Allerdings wurden die gesetzten Ausgänge vom RevPiCompact nicht angesteuert, obwohl eine entsprechende 1 im Prozessabbild stand.

Hier hilft nur ein Neustart des Revolution Pi, um die Synchronisation des Prozessabbildes mit den IOs wieder zu ermöglichen.
Das ist natürlich im normalen Anlagenbetrieb keine Lösung.

Welche Umstände genau zu dem Absturz der Synchronisation geführt haben konnten wir noch nicht im Detail analysieren, da dieser Zustand immer nur im zu bestimmten Zeitpunkten mitten im Betrieb (nicht direkt nach Neustart) auftritt.

Logs konnten wir dementsprechend auch noch nicht viele sammeln, in den `kern.log`s gab es zum Zeitpunkt des Fehlerauftretens, und auch danach beim Testen / Debuggen allerdings keinerlei ausgaben.

Über entsprechende Rückmeldungen zum Problem / Ideen, wie wir den Fehler provozieren und damit nachstellbar machen können, wären wir sehr dankbar.
Auch über einen Hinweis, ob es abgesehen von der Pictory Version unterschiede durch den OS / ARM Wechsel gegeben haben könnte.

MfG Simvei001

[RamiGspo]

Hallo Simon,

Danke für die klaren Details zu deinem Aufbau und Problem.

Zunächst ein kurzer Hinweis: Unsere aktuellste Version ist mittlerweile „Bookworm“, nicht mehr Bullseye. Die letzte Version ist RevPi Bookworm 05/2025 (Download hier: https://revolutionpi.com/de/support/downloads#c1069) . Du kannst deine bestehende Pictory-Konfiguration auch unter Bookworm weiterhin verwenden, da diese kompatibel bleibt. Bullseye wird von uns aber weiterhin gepflegt.

Zwischen „Stretch“ und „Bullseye“ gab es noch eine Version („Buster“), wodurch sich Kernel, Treiber und Libraries mehrfach verändert haben. Das kann in seltenen Fällen Einfluss auf die IO-Synchronisation haben.

Wie du korrekt schreibst, ist ein „Neustart“ des RevPi im laufenden Anlagenbetrieb keine wirkliche Lösung. Daher ist es wichtig, die Ursache gezielt zu identifizieren und sie sauber einzugrenzen.

Noch eine wichtige Rückfrage von meiner Seite:
Hast du das Update auf Bullseye direkt durch Flashen des Images gemacht, oder hast du Bullseye per „apt“-Befehl über die Kommandozeile installiert?
Falls du geflasht hast: Hast du danach ein

Code: Select all

sudo apt update && sudo apt upgrade

durchgeführt?
Nur so ist sichergestellt, dass dein System alle aktuellen Kernel, Paketen und Updates enthält.
Falls du das noch nicht gemacht hast, würde ich dich bitten, dies nachzuholen, da wir seit Veröffentlichung der letzten Bullseye-Images mehrere Änderungen und Verbesserungen im Kernel und System vorgenommen haben, die genau solche sporadischen Effekte verhindern können.

Falls der Fehler nach einem Update erneut auftritt, kannst du unter Bullseye das Tool "revpi-sos" verwenden, um alle relevanten Logs und Statusdaten automatisiert zu sammeln, sobald der Fehler auftritt. Dann könntest du uns den sos-report senden. Infos dazu findest du hier: https://kunbus-gmbh.atlassian.net/servi ... 2036400208

Falls es für dich möglich ist, wäre es außerdem hilfreich, unsere aktuelle Bookworm-Version parallel zu deinem bestehenden System zu testen, um herauszufinden, ob der Fehler dort weiterhin auftritt oder bereits behoben ist. So könnten wir gemeinsam schneller eingrenzen, ob der Fehler noch systemseitig auftritt oder durch die Updates bereits gelöst wurde.

Viele Grüße,

[Sensorik]

Hallo Simon,

ich hatte soeben ein ähnliches Problem mit Nodered.
Ich glaube das Problem bei mir gefunden zu haben. Ich habe leider unabsichtlich einmal einen String geschickt und dann ist in Nodered der PIN: PwmDurycycle auf meiner IO-Karte ausgefallen, obwohl ich den Pin über piTest ansteuern konnte.
Vielleicht ist es bei dir auch ein ähnliches Problem - achte auf das Datenformat.

lg, Sensorik

[Simvei001]

Hast du das Update auf Bullseye direkt durch Flashen des Images gemacht, oder hast du Bullseye per „apt“-Befehl über die Kommandozeile installiert?
Falls du geflasht hast: Hast du danach ein

Code: Select all

sudo apt update && sudo apt upgrade

durchgeführt?
Nur so ist sichergestellt, dass dein System alle aktuellen Kernel, Paketen und Updates enthält.
Falls du das noch nicht gemacht hast, würde ich dich bitten, dies nachzuholen, da wir seit Veröffentlichung der letzten Bullseye-Images mehrere Änderungen und Verbesserungen im Kernel und System vorgenommen haben, die genau solche sporadischen Effekte verhindern können.

Falls der Fehler nach einem Update erneut auftritt, kannst du unter Bullseye das Tool "revpi-sos" verwenden, um alle relevanten Logs und Statusdaten automatisiert zu sammeln, sobald der Fehler auftritt. Dann könntest du uns den sos-report senden. Infos dazu findest du hier: https://kunbus-gmbh.atlassian.net/servi ... 2036400208

Wir haben die Anlagen auf denen der Fehler auftritt komplett neu geflasht. (Daher auch der Wechsel von armhf auf arm64.)
Zu unserem normalen Installationsprozess gehärt auch eine

Code: Select all

apt update && apt upgrade

Routine, sodass beide Anlagen zum Start auf aktuellstem Stand gewesen sind. Mittlerweile sind bereits wieder ein paar Pakete veraltet, siehe Anlage unten.

Eine der beiden Anlagen, die aktuell diesen Fehler aufweisen kann ich updaten und schauen, ob der Fehler noch auftritt und dann

Code: Select all

revpi-sos

ausführen.
Für bookworm Tests steht aktuell noch keine weitere Anlage zur Verfügung, evtl. kann ich aber nach dem bullseye Test, diese Anlage auf bookworm upgraden und dort erneut testen, dafür muss ich aber auch unsere Software neu bauen, daher kann sich dort eine Rückmeldung noch einiges länger hinauszögern.

Ich hoffe, dass sich mit den bullseye Logs (sollte der Fehler bestehen bleiben, schon einiges mehr "sehen" lässt.).




Anlage:

Code: Select all

curl/oldstable-security 7.74.0-1.3+deb11u15 arm64 [upgradable from: 7.74.0-1.3+deb11u14]
dns-root-data/oldstable-security,oldstable-security 2024071801~deb11u1 all [upgradable from: 2024041801~deb11u1]
libblockdev-crypto2/oldstable-security 2.25-2+deb11u1 arm64 [upgradable from: 2.25-2]
libblockdev-fs2/oldstable-security 2.25-2+deb11u1 arm64 [upgradable from: 2.25-2]
libblockdev-loop2/oldstable-security 2.25-2+deb11u1 arm64 [upgradable from: 2.25-2]
libblockdev-part-err2/oldstable-security 2.25-2+deb11u1 arm64 [upgradable from: 2.25-2]
libblockdev-part2/oldstable-security 2.25-2+deb11u1 arm64 [upgradable from: 2.25-2]
libblockdev-swap2/oldstable-security 2.25-2+deb11u1 arm64 [upgradable from: 2.25-2]
libblockdev-utils2/oldstable-security 2.25-2+deb11u1 arm64 [upgradable from: 2.25-2]
libblockdev2/oldstable-security 2.25-2+deb11u1 arm64 [upgradable from: 2.25-2]
libc-bin/oldstable 2.31-13+rpt2+rpi1+deb11u13 arm64 [upgradable from: 2.31-13+rpt2+rpi1+deb11u12]
libc-dev-bin/oldstable 2.31-13+rpt2+rpi1+deb11u13 arm64 [upgradable from: 2.31-13+rpt2+rpi1+deb11u12]
libc-devtools/oldstable 2.31-13+rpt2+rpi1+deb11u13 arm64 [upgradable from: 2.31-13+rpt2+rpi1+deb11u12]
libc-l10n/oldstable,oldstable 2.31-13+rpt2+rpi1+deb11u13 all [upgradable from: 2.31-13+rpt2+rpi1+deb11u12]
libc6-dbg/oldstable 2.31-13+rpt2+rpi1+deb11u13 arm64 [upgradable from: 2.31-13+rpt2+rpi1+deb11u12]
libc6-dev/oldstable 2.31-13+rpt2+rpi1+deb11u13 arm64 [upgradable from: 2.31-13+rpt2+rpi1+deb11u12]
libc6/oldstable 2.31-13+rpt2+rpi1+deb11u13 arm64 [upgradable from: 2.31-13+rpt2+rpi1+deb11u12]
libcurl3-gnutls/oldstable-security 7.74.0-1.3+deb11u15 arm64 [upgradable from: 7.74.0-1.3+deb11u14]
libcurl4/oldstable-security 7.74.0-1.3+deb11u15 arm64 [upgradable from: 7.74.0-1.3+deb11u14]
libgssapi-krb5-2/oldstable-security 1.18.3-6+deb11u7 arm64 [upgradable from: 1.18.3-6+deb11u6]
libicu67/oldstable-security 67.1-7+deb11u1 arm64 [upgradable from: 67.1-7]
libk5crypto3/oldstable-security 1.18.3-6+deb11u7 arm64 [upgradable from: 1.18.3-6+deb11u6]
libkrb5-3/oldstable-security 1.18.3-6+deb11u7 arm64 [upgradable from: 1.18.3-6+deb11u6]
libkrb5support0/oldstable-security 1.18.3-6+deb11u7 arm64 [upgradable from: 1.18.3-6+deb11u6]
libssl1.1/oldstable 1.1.1w-0+deb11u3+rpt1 arm64 [upgradable from: 1.1.1w-0+deb11u2+rpt1]
libudisks2-0/oldstable-security 2.9.2-2+deb11u2 arm64 [upgradable from: 2.9.2-2+deb11u1]
locales/oldstable,oldstable 2.31-13+rpt2+rpi1+deb11u13 all [upgradable from: 2.31-13+rpt2+rpi1+deb11u12]
net-tools/oldstable-security 1.60+git20181103.0eebece-1+deb11u2 arm64 [upgradable from: 1.60+git20181103.0eebece-1+deb11u1]
openssl/oldstable 1.1.1w-0+deb11u3+rpt1 arm64 [upgradable from: 1.1.1w-0+deb11u2+rpt1]
python3-pkg-resources/oldstable-security,oldstable-security 52.0.0-4+deb11u2 all [upgradable from: 52.0.0-4+deb11u1]
revpi-sos-report/bullseye,bullseye 1.3.2-1+revpi11+1 all [upgradable from: 1.3.0-1+revpi11+1]
sudo/oldstable-security 1.9.5p2-3+deb11u2 arm64 [upgradable from: 1.9.5p2-3+deb11u1]
udisks2/oldstable-security 2.9.2-2+deb11u2 arm64 [upgradable from: 2.9.2-2+deb11u1]

[Simvei001]

Hallo Simon,

ich hatte soeben ein ähnliches Problem mit Nodered.
Ich glaube das Problem bei mir gefunden zu haben. Ich habe leider unabsichtlich einmal einen String geschickt und dann ist in Nodered der PIN: PwmDurycycle auf meiner IO-Karte ausgefallen, obwohl ich den Pin über piTest ansteuern konnte.
Vielleicht ist es bei dir auch ein ähnliches Problem - achte auf das Datenformat.

lg, Sensorik

Da wir über unser Tooling mit dem wir auf das Prozessabbild Zugreifen bisher in allen alten Varianten keine Probleme hatten (und auch nur Funktionalität zum schreiben von Bool-Werten implementiert/in Nutzung haben) denke ich nicht, dass wir mit dem Zugriff auf das Prozessabbild an sich Probleme haben.
Allerdings vermute ich auch, dass sich bei irgendeiner Schreib-Operation etwas an die falsche Stelle verirrt und dadurch die Probleme entstehen.

Ich hatte darauf spekuliert, dass sich zwischen der arm64 und armhf Variante des Prozessabbildes ein unterschiedlicher Offset ergibt, da einmal mit 64Bit und einmal mit 32Bit großer Adressierung gerechnet wird, aber das scheint laut Pictory Konfiguration und Hexdump von /dev/piControl0 alles identisch zu sein.

[nicolaiB]

Die Offsets sollten durch das Update von 32-bit auf 64-bit nicht betroffen sein, da die Logik im Hintergrund abstrahiert ist. Wenn der Fehler ebenfalls mit piTest auftritt, scheint das Problem wo anders zu liegen. Gibt es in /var/log/kern.log Fehlermeldungen? Hast du es mal mit einer "frischen" piCtory Konfiugration probiert?