Hallo,

ich betreibe einen Rasberry pi b und b+ mit lizenzierter Runtime. An beiden habe ich einen i2c Multiplexer (PCA9544) angeschlossen der mir auf 4 Kanälen i2c Geräte beschreibt und ausliest.
an Kanal 0 sind zwei PCf8574P, an Kanal 1 ist eine RTC DS1307, an Kanal 2 ist ein PCf8574AP und an Kanal 3 sind 6 weitere PCf8574P angeschlossen.
Die Geräte (inklusive multiplexer) steuere ich mit dem Baustein "i2c_Master" an.

Alles funktioniert soweit sehr gut. ich schalte zwischen den 4 Kanälen um, lese und schreibe. Ich habe auch Zugriff auf alle einzelnen Geräte.

jetzt das Problem: in unregelmäßigen Abständen "hängt" sich die Runtime auf. Der Raspberry kann von der SDK nicht mehr erreicht werden jedoch über ssl kann ich auf den Raspberry noch zugreifen.

Folgendes habe ich schon probiert:
Ich habe die Zykluszeit auf 50 millisekunden erhöht, diese aber auch auf freilaufend geschaltet (freilaufend liegt die zykluszeit bei ca. 2.5 ms). Weiterhin habe ich die Visualisierung deaktiviert bzw. komplett ausgeschaltet. ich habe auch einen Mechanismus eingebaut der nach dem Start prüft, welche Geräte überhaupt über i2c erreichbar sind und nur diese werden gelesen oder geschrieben.

Das Programm das ich verwende habe ich komplett ohne i2c laufen lassen. Die Ein und Ausgänge habe ich mit einen demobaustein simuliert. In dieser Konstellation läuft alles sauber ohne das sich etwas beendet. (Fehler in der Programmlogik sind damit ausgeschieden).

Gibt es eine Überwachung für den I2c_master?
gibt es einen Reset für den I2c_Master?
Gibt es Logs, die ich auf dem Raspberry einsehen kann, in denen vielleicht die Ursache protokolliert wird?
Gibt es die Möglichkeit die Runtime neu zu starten ohne den Raspberry pi komplett neu zu booten, bzw. zu reseten wenn diese einen Fehler aufwirft und dies jedoch nur passiert wenn sich der i2c Bus verabschiedet?

Hi,

Zitat:
Gibt es eine Überwachung für den I2c_master?

aktuell nicht, du kannst mal wenn es passiert unter Linux schauen ob alles noch geht - (um herauszufinden ob es an der Runtime liegt)
installier doch mal:
sudo apt-get install i2c-tools
dann wenn es passiert ist:
sudo i2cdetect -y 0
schauen ob hier noch was kommt.

Zitat:
gibt es einen Reset für den I2c_Master?

aktuell nicht, du könntest vermutlich das modul aus dem kernel entladen und wieder neu laden
sudo rmmod i2c-dev
sudo modprobe i2c-dev
habe das nicht getestet bin auch nicht sicher ob es reicht nur das Modul neu zu laden, denke du wirst es herausfinden.

Zitat:
Gibt es Logs, die ich auf dem Raspberry einsehen kann, in denen vielleicht die Ursache protokolliert wird?

cat /tmp/codesyscontrol.log

Zitat:
Gibt es die Möglichkeit die Runtime neu zu starten ohne den Raspberry pi komplett neu zu booten, bzw. zu reseten wenn diese einen Fehler aufwirft und dies jedoch nur passiert wenn sich der i2c Bus verabschiedet?

sudo service codesyscontrol stop
sudo service codesyscontrol start

Grüße
Edwin

Danke,

das ging ja prompt. ich werde das alles mal probieren.

Danke nochmal für die schnelle Antwort.

Hallo Edwin,

nachdem das Programm wieder gestoppt ist habe ich folgendes probiert:

1. ssl Verbindung zum rapsberry aufgebaut:
   -> OK

2. prüfen ob mit sudo i2cdetect -y 0 etwas ausgegeben wird:
   -> Error: Could not open file ‚/dev/i2c-0‘ or ‚/dev/i2c/0‘: No such file or directory

3. prüfen ob mit sudo i2cdetect -y 1 etwas ausgegeben wird:
   -> Ergebniss:

   pi@raspberrypi ~ $ sudo i2cdetect -y 1
   0 1 2 3 4 5 6 7 8 9 a b c d e f
   00: -- -- -- -- -- -- -- -- -- -- -- -- --
   10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
   20: 20 21 22 23 24 25 -- -- -- -- -- -- -- -- -- --
   30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
   40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
   50: -- -- -- -- -- -- -- -- 58 -- -- -- -- -- -- --
   60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
   70: 70 -- -- -- -- -- -- --

4. probiert das modul zu entladen mit sudo rmmod i2c-dev
   -> Error: Module i2c_dev is in use

5. errorlog ausgeben:
   -> anhang Codesyscontrol.log

wenn dir das bitte noch mal anschauen könntest?

danke schon in voraus für deine Hilfe

gruß michl

Codesyscontrol.log.txt [288.77 KiB]

Hallo Michel,

mein Fehler du must natürlich i2cdetect -y 1
das Model A verwendet I2C 0 und das Pi Model B den I2C1 sorry also so:

sudo i2cdetect -y 1
aber hast du ja selber festgestellt... für mich sieht es so aus als ware alles ok am I2C.

du könntest mal den du eh ne ssh hast und die auch weiter bestehen bleibt
top
aufrufen und schauen ob der speicherverbrauch und auch die Auslastung der codesyscontrol für den fall
das du das Gerät nicht mehr erreichen kannst
Grüße
Edwin

Grüße
Edwin

Hallo Edwin,

das habe ich mir schon gedacht, deshalb habe ich es wie oben gepostet ausprobiert.

nichts desto trotz hat sich die runtime wieder aufgehangen. gerade eben nochmal.

gibt es die Möglichkeit nicht nur die runtime zu beenden und wieder zu starten

(sudo service codesyscontrol stop
sudo service codesyscontrol start)

sondern auch das programm auf run zu schalten?

aktuell hilft nur ein reboot des raspberry.

Hallo Michel,

also wenn du stop und start machst dann muss das program automatisch loslaufen.. (du machst ja sicher ein Bootprojekt)
(Wenn du nach stop / start versuchst mit CODESYS online zu gehen, kommst du dann einfach online oder must du das Projekt neu downloaden)
Schau in diesem Zustand mal ins SPS log und zwar oben in CODESYS auf dem Device SPS Log

• auf Linux seite in der shell

mit:

top

aufrufen und schauen ob der Speicherverbrauch und auch die Auslastung der codesyscontrol für den fall
das du das Gerät nicht mehr erreichen kannst ansteigt
BR
Edwin

Hallo Edwin,

ja, ich erzeuge ein Bootprojekt. Es sollte theoretisch immer eine lauffähige Version, egal in welcher
Entwicklungsphase ich mich befinde auf dem Raspberry vorhanden sein. Dies bestätigt auch die Tatsache das er nach einem Reboot wie gewohnt meine Aktoren ansteuert.

Zur Diagnose:
ich kann gar nicht mehr online gehen. meine Entwicklungsumgebung meldet keine Verbindung zum Raspberry, das gerät ist nicht mehr erreichbar. Auch wenn ich auf Gerät suchen gehe, wird mir kein verfügbares Gerät mehr angezeigt obwohl ich über ssl auf dem Raspberry selbst noch Zugriff habe.

Nach dem Manuellen Stoppen und Starten der läuft diese augenscheinlich hoch, es wird zumindest eine lizenzbackup gemacht, jedoch die programmausführung startet nicht.

Gerade eben während ich schreibe ist das Problem wieder aufgetreten.

ich hatte die webvisualisierung in einem chrome fenster geöffnet und war nicht mit der sdk online.
keine logs und auch kein zugriff mehr über ssl.

reboot -> alles ok

danke

Hallo,

ich wollte noch einmal Rückmeldung betreffs meines Problems mit dem i2c Bus geben.

nachdem ich nochmals und abermals meine Schaltung überprüft habe bin ich bei mir im Programm auf einen
FB gestoßen den ich vor geraumer Zeit programmiert habe. Das Problem konnte ich im FB lokalisieren
und hat rein überhaupt nichts mit der I2c Ansteuerung zu tun. Bei mir ist ein TP Baustein in die Sektion "var_stat" gerutscht.
Da ich diesen FB jedoch als Multiinstanz über ein Array handhabe hat es hier gekracht.

nachdem ich nur einen Rollo, auf einen i2c bus mit einer Zykluszeit von ca. 2,8 millisekunden bearbeitet habe, liegt die
Zykluszeit des Gesamtsystems mit 4 i2c bussystemen sowie 12 aktiven Teilnehmern
+ Realtimeclock über i2c und 64 aktiv angesteuerten Rollos zwischen 1,6 und 1,8 Millisekunden.

Die Steuerung ist jetzt 2 tage ohne Unterbrechung gelaufen, ohne das Probleme aufgetreten sind.

Ich Möchte mich nochmals für die Schnelle Hilfe bei Edwin bedanken da ich wahrscheinlich immer noch in der falschen Richtung suchen würde.

gruß, michl

Hallo,

nachdem ich nochmal alles kontrolliert habe und auch einen Kollegen mit ins Boot genommen habe
musste ich feststellen das der i2c bzw. Codesys doch noch ein Problem zu haben scheint.

Ich habe keine sonderlichen Auslastungen oder Abläufe bekomme jedoch nach einer zeit die immer ein
vielfaches von fast genau 1:58 ist das zuvor beschriebene Phänomen.

Codesys geht in Stop, keine Fehlermeldung, kein Zugriff auf Codesys mehr möglich.
boote ich den Raspberry danach wieder alles in Ordnung.

kann es vielleicht sein das ich mit meiner Lizenz ein Problem habe oder Codesys mit der Lizenz ein Problem hat?

wie gesagt nach den Testlauf über 3 Tage trat das Phänomen immer nach einer vielfachen Zeit von ca. 1:58 H auf.
einmal nach knapp 12 Stunden, einmal nach knapp 4 usw.

Mein Kollege (sehr erfahren) hat mein Programm durchleuchtet und auch keine stellen
gefunden die Überläufe oder sonstiges erzeugen würden.

gruß michl

Hallo,

kannst du mal schauen wenn es passiert (also du m it CODESYS nicht mehr drauf kommst)
1. kommt man mit ssh noch drauf?
2. mit 'top' schauen ob die Runtime noch läuft (codesyscontrol)
3. Ist das ein B+ Model?
4. versuche die Runtime ohne zu booten neu zu starten mit sudo /etc/init.d/codesyscontrol start
5. cat cat /tmp/codesyscontrol.log

denke das sollte mich/uns weiterbringen

Grüße
Edwin

Zu 1: ja man kommt noch mit ssh drauf. Ohne Probleme
Zu 2: ja, codesyscontrol läuft noch jedoch ohne CPU Auslastung
Zu 3: ja, es ist ein B+ Modell
Zu 4: habe ich versucht. Er zeigt zwar an das die codesyscontrol started ist jedoch als Resultat keine Ausführung meines Programms
Zu 5: der Screenshot zeigt das er keine Lizenz hat, bzw. im demomodus läuft. Ich habe eine gültige Lizenz erworben und auf dem Raspberry drauf.

ich habe die screenshots zu den punkten erstellt und diese mal angehängt.

danke für die Bemühungen

grüße
michl

Hallo Mike,

was genau ist im Vergleich zum original Image geändert - kann es sein das du die I2C Baudrate
oder ähnliches änderst?
Es gibt im englischen Forum auch einen User der sporadisch das selbe Problem hat,
wir sind dabei das ganze zu reproduzieren momentan tritt es bei uns hier noch nicht auf.
Noch eine Frage, verwendest du das Image aus dem Store download oder ein anderes z.B von raspberrypi.org?

Grüße
Edwin

CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions

hallo,

nein, ich habe nichts geändert. das image läuft so wie es ist. lediglich die updates habe ich installiert die
über raspi-config angeboten werden.

ich kann sd karten image auf meinen server hochladen und und zur verfügung stellen.
ebenso das programm das ich dafür geschrieben habe wenn dies bei den tests
weiterhelfen würde.

gruß michl

Hallo Mike,

kannst du einen Versuch machen,
nimm das original SD Image von raspberrypi.org und installier bitte darauf das debian packet das auch im download zip aus
unserem Store ist.
Dann nochmals testen.
Nein, das ist nicht das Problem auch mit Raspberrypi.org Image tritt das Problem auf,
scheint ein Problem im Linux Kernel zu sein, GPU Interrupts hängen, wie auch immer das passieren kann wir bleiben dran.

Grüße
Edwin

CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions

hallo,

entschuldigung,

ich war eine Zeitlang weg vom schuß.

ja, ich habe probiert das image auf einem pi B nochmal ganz neu aufzusetzen.
hat augenscheinlich auch super geklappt.

steigt jedoch trotzdem aus.

mfg michl

Hi,
danke für die Info, wir suchen nach einer Lösung für dieses Problem.
Grüße
Edwin

hallo edwin,

ich lade das debian wheezy und werde es testen.

gruß michl

Hallo Michl,
ja vielleicht wäre ne Idee das neue Image von Dezember von Raspberry.org zuverwenden.

es scheint ein Problem in einem Kernelmodul von wheezy zu sein,
das blockiert dann irgendwann.. in dmesg sieht man das im Fehlerfall.
Für's "alte" Image könnte man mit:

sudo apt-get update
sudo rpi-update

dden Kernel aktualisieren, dann nochmal den Dauertest starten.
Grüße
Edwin

Hallo Mike,

ich habe das gleiche Problem mit dem I2C, ich habe eine Heizungssteuerung programmiert, die hängt sich auch auf alle Tage oder nach ein paar Std.
Ich habe nur 3 PCF8574 und einen Uhrenbaustein am Bus hängen (ist ja gar nix). Ich wollte diese Weihnachten einbauen. Da der I2C nicht stabil läuft muss ich noch warten.

Hallo,

ich habe jetzt sehr viele tests gemacht.

Basis war immer das original codesysimage für den raspberry Pi B

ich habe ohne updates sowie mit aktuellen updates getestet jedoch ohne erfolg.
sporarische aufhänger sind konnte ich nicht vermeiden.

ich habe weiterhin auch noch zum thema raspberri Pi und i2c rechachiert.

folgendes scheint wahrscheinlich fakt zu sein: der raspberry pi hat ein problem mit
dem Clockstretch.

vielleicht hilft das weiter

gruß michl

Hallo,
hat schon jemand eine Lösung für das Problem gefunden? Bei mir hängt sich die PI auch auf.
Ich überlege, ob ich besser den SPI Anschluss verwende?!

Hallo!
Habe auch selbiges Problem. Eine genaue Laufzeit ist ebenfalls nicht auszumachen - mal hält der Raspi 7 Tage lang durch - mal kann schon nach ein paar vielfache von 2h Schluss sein. Hat jemand schon versucht die Taktrate des I2C runter zu stellen um damit dieses Problem zu umgehen?
Gruß

Hi,
am besten du postest hier das log aus /tmp
also cat /tmp/codesyscontrol.log wenn das Problem ansteht.
(falls das CODESYS Laufzeitsystem dann noch läuft)

Grüße
Edwin