Hallo,
ich habe ein Problem bei der Verwendung des PROFINET IRT Slaves.
Nach einer gewissen Betriebszeit, circa zwischen 5 und 50 Minuten, meldet das Gateway einen Fehler (Power rot, blinkt; Diag LED rot, an), und das Prozessabbild wird nicht mehr aktualisiert. Ein Reset von picontrol mit "piTest -x" setzt dabei nur alle Ein- und Ausgänge auf 0 zurück, ein vollständiger Neustart des Pi behebt das Problem aber temporär. Das Verhalten existiere schon seit der ersten Inbetriebname des Pi mit dem stretch image, besteht aber auch mit aktueller Software.
Im PROFINET wird vom Gateway ein Fehler in der "Nachbarschaft" gemeldet. Wodurch könnte so ein Verhalten verursacht werden?
MfG,
Lukas
edit: Ein Aufspielen des neuen Stretch Image von (3/2019) scheint das Problem behoben zu haben. Falls es trotzdem für eine Fehlersuche interessant ist:
Im kern.log stand, dass sich der Ethernet Controller, der so wie ich das verstehe für die picontrol Modulkommunition zuständig ist, regelmäßig neu initialisiert hat, was manchmal mit der Störung einherging.
PROFINET Gateway Problem
Re: PROFINET Gateway Problem
Man soll den Tag nicht vor dem Abend loben, wir haben anscheinend nur ein Problem durch ein anderes ausgetauscht.
Trotz einer Zykluszeit von 10ms und ohne Warnungen von revpimodio bei der Ausführung meines Python Programmes kommen nur circa ein Drittel aller im ~11ms Takt geschriebenen Daten aus dem Profinet am Rev Pi an. Zusätzlich wird scheinbar zufällig manchmal das komplette Prozessabbild auf 0 gesetzt.
Ein blick auf das kern.log zur Zeit eines solchen Resets:
Für Ideen, wo das Problem zu finden ist, wäre ich sehr dankbar!
Trotz einer Zykluszeit von 10ms und ohne Warnungen von revpimodio bei der Ausführung meines Python Programmes kommen nur circa ein Drittel aller im ~11ms Takt geschriebenen Daten aus dem Profinet am Rev Pi an. Zusätzlich wird scheinbar zufällig manchmal das komplette Prozessabbild auf 0 gesetzt.
Ein blick auf das kern.log zur Zeit eines solchen Resets:
Der Offset zwischen den erreichten und erwarteten Paketen hat sich nach den id requests verschoben.Mar 21 15:35:27 RevPi100257 kernel: [ 2279.809243] piControl: pileft: received data packet ack 0xa8, expected 0xa9
Mar 21 15:35:27 RevPi100257 kernel: [ 2279.837279] piControl: pileft: received data packet ack 0xa9, expected 0xaa
Mar 21 15:35:27 RevPi100257 kernel: [ 2279.865376] piControl: pileft: received data packet ack 0xaa, expected 0xab
Mar 21 15:35:27 RevPi100257 kernel: [ 2279.902638] piControl: pileft: received data packet ack 0xab, expected 0xac
Mar 21 15:35:27 RevPi100257 kernel: [ 2279.939824] piControl: pileft: received data packet ack 0xac, expected 0xad
Mar 21 15:35:27 RevPi100257 kernel: [ 2279.967760] piControl: pileft: received data packet ack 0xad, expected 0xae
Mar 21 15:35:27 RevPi100257 kernel: [ 2279.996679] piControl: pileft: received data packet ack 0xae, expected 0xaf
Mar 21 15:35:27 RevPi100257 kernel: [ 2280.082294] piControl: pileft: timeout
Mar 21 15:35:27 RevPi100257 kernel: [ 2280.090064] piControl: pileft: id request
Mar 21 15:35:27 RevPi100257 kernel: [ 2280.172271] piControl: pileft: timeout
Mar 21 15:35:27 RevPi100257 kernel: [ 2280.182445] piControl: pileft: id request
Mar 21 15:35:28 RevPi100257 kernel: [ 2280.272276] piControl: pileft: timeout
Mar 21 15:35:28 RevPi100257 kernel: [ 2280.275021] piControl: pileft: id request
Mar 21 15:35:28 RevPi100257 kernel: [ 2280.284501] piControl: pileft: id response (module type 79 hw V1 sw V1.2 svn 12531 serial 4179 mac c8:3e:a7:00:4f:01)
Mar 21 15:35:28 RevPi100257 kernel: [ 2280.294020] piControl: pileft: received id response while awaiting data packet
Mar 21 15:35:28 RevPi100257 kernel: [ 2280.321412] piControl: pileft: received id response while awaiting data packet
Mar 21 15:35:28 RevPi100257 kernel: [ 2280.368028] piControl: pileft: id request, resetting connection
Mar 21 15:35:28 RevPi100257 kernel: [ 2280.377779] piControl: pileft: received data packet while awaiting id response
[...]
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.617796] piControl: pileft: id request
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.702324] piControl: pileft: timeout
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.710285] piControl: pileft: id request
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.719626] piControl: pileft: id response (module type 79 hw V1 sw V1.2 svn 12531 serial 4179 mac c8:3e:a7:00:4f:01)
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.729080] piControl: pileft: received id response while awaiting data packet
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.747581] piControl: pileft: received id response while awaiting data packet
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.802312] piControl: pileft: timeout
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.803398] piControl: pileft: id request
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.813032] piControl: pileft: id response (module type 79 hw V1 sw V1.2 svn 12531 serial 4179 mac c8:3e:a7:00:4f:01)
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.842769] piControl: pileft: received id response while awaiting data packet
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.870668] piControl: pileft: received data packet ack 0x2, expected 0x5
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.898696] piControl: pileft: received data packet ack 0x3, expected 0x6
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.927730] piControl: pileft: received data packet ack 0x4, expected 0x7
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.955593] piControl: pileft: received data packet ack 0x5, expected 0x8
Mar 21 15:35:31 RevPi100257 kernel: [ 2283.992493] piControl: pileft: received data packet ack 0x6, expected 0x9
Mar 21 15:35:31 RevPi100257 kernel: [ 2284.030003] piControl: pileft: received data packet ack 0x7, expected 0xa
Mar 21 15:35:31 RevPi100257 kernel: [ 2284.058642] piControl: pileft: received data packet ack 0x8, expected 0xb
Mar 21 15:35:31 RevPi100257 kernel: [ 2284.086794] piControl: pileft: received data packet ack 0x9, expected 0xc
Mar 21 15:35:31 RevPi100257 kernel: [ 2284.123923] piControl: pileft: received data packet ack 0xa, expected 0xd
Für Ideen, wo das Problem zu finden ist, wäre ich sehr dankbar!
Re: PROFINET Gateway Problem
Hallo Lukas,
das ist ein bekanntes Problem. Zurzeit arbeiten wir an einer Lösung hierfür.
das ist ein bekanntes Problem. Zurzeit arbeiten wir an einer Lösung hierfür.
Re: PROFINET Gateway Problem
Hi,
gibt es bereits eine Loesung fuer das von LukasN beschriebene Problem? Das Thema ist schon ein Jahr alt..
Anbei die Fehlermeldungen aus unererer Profinet-Kommunikation:
gibt es bereits eine Loesung fuer das von LukasN beschriebene Problem? Das Thema ist schon ein Jahr alt..
Anbei die Fehlermeldungen aus unererer Profinet-Kommunikation:
Code: Select all
[Thu Jun 18 13:54:39 2020] piControl: pileft: received data packet ack 0xa6, expected 0xa7
[Thu Jun 18 13:54:39 2020] piControl: pileft: received data packet ack 0xa7, expected 0xa8
[Thu Jun 18 13:54:39 2020] piControl: pileft: received data packet ack 0xa8, expected 0xa9
[Thu Jun 18 13:54:39 2020] piControl: pileft: received data packet ack 0xa9, expected 0xaa
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xaa, expected 0xab
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xab, expected 0xac
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xac, expected 0xad
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xad, expected 0xae
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xae, expected 0xaf
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xaf, expected 0xb0
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb0, expected 0xb1
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb1, expected 0xb2
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb2, expected 0xb3
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb3, expected 0xb4
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb4, expected 0xb5
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb5, expected 0xb6
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb6, expected 0xb7
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb7, expected 0xb8
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb8, expected 0xb9
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xb9, expected 0xba
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xba, expected 0xbb
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xbb, expected 0xbc
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xbc, expected 0xbd
[Thu Jun 18 13:54:40 2020] piControl: pileft: received data packet ack 0xbd, expected 0xbe
Re: PROFINET Gateway Problem
Ja das Problem wurde zwischenzeitlich beseitigt:
Die Ursache dieses Problems ist übrigens im piControl Commit da199ccd2099 dokumentiert. Kurz gesagt kommt die Gateway-Firmware nicht damit klar, dass sie andere Pakete auf dem Ethernet-Interface zum RevPi sieht als die Feldbus-Pakete. Denn seit dem Kernel Release "12 Mar 2019" sind die Ethernet-Chips an der PiBridge (für die Feldbus-Kommunikation) als reguläre Interfaces "pileft" und "piright" unter Linux sichtbar und dann kann es passieren, dass auch DHCP und sonstige Pakete an die Gateways geschickt werden.
- Stelle sicher, dass auf der Maschine ein Kernel installiert ist, der mindestens das Release-Datum "4 Sep 2019" hat (siehe Kernel Releases). Welcher Kernel aktuell läuft, siehst Du mit "uname -a". Du kannst den Kernel auf den neuesten Stand bringen mit "sudo apt-get update && sudo apt-get install raspberrypi-kernel". Anschließend rebooten.
- Stelle sicher, dass die Firmware auf dem Gateway auf dem neuesten Stand ist. Du kannst die Firmware aktualisieren, indem Du zunächst sicherstellst, dass das neueste "revpi-firmware" Paket auf dem RevPi installiert ist. Das geht mit "sudo apt-get update && sudo apt-get install revpi-firmware". Anschließend kannst Du mit "piTest -f" die Firmware des Gateways prüfen und gegebenenfalls aktualisieren.
Die Ursache dieses Problems ist übrigens im piControl Commit da199ccd2099 dokumentiert. Kurz gesagt kommt die Gateway-Firmware nicht damit klar, dass sie andere Pakete auf dem Ethernet-Interface zum RevPi sieht als die Feldbus-Pakete. Denn seit dem Kernel Release "12 Mar 2019" sind die Ethernet-Chips an der PiBridge (für die Feldbus-Kommunikation) als reguläre Interfaces "pileft" und "piright" unter Linux sichtbar und dann kann es passieren, dass auch DHCP und sonstige Pakete an die Gateways geschickt werden.
-
- matthias_k
- Posts: 5
- Joined:
Re: PROFINET Gateway Problem
Hallo,
das Thema ist zwar schon ein wenig älter, aber vermutlich noch nicht erledigt. Ich verwende einen RevPiCore 3+ mit Profibus Gateway, welche über die piBridge (piright) miteinander gekoppelt sind. Grundsätzlich funktioniert alles problemlos, allerdings trat bei mir jetzt schon zweimal (immer jeweils nach einem Neustart) der hier beschriebene Fehler auf. Besonders ärgerlich sind die resets und das damit verbundenen 0 setzen des Prozessabbildes, was ja auch Sollwerte betrifft, die ich über den Profibus kommuniziere.
Das verwendete Revpi Kernel release ist mit 26.03.2021 aktuell, die Firmware-Version mit der V1.0 soll laut piTest -f die aktuellste sein, aber vermutlich noch nicht um den hier beschriebenen Bug bereinigt, oder?
Wenn ich das Profibus-Gateway also noch nicht um den Fehler bereinigen kann würde ich versuchen mich der Lösung mit dem netfilter hook auf die Gateway Frames mit dem ethertype 0x419c auseinander zu setzen. Kann das sporadische auftreten ggf. auch mit der von mir verwendeten UFW (firewall) zusammenhängen, die auf IPtables bzw. netfilter basiert?
Beste Grüße
Matthias
das Thema ist zwar schon ein wenig älter, aber vermutlich noch nicht erledigt. Ich verwende einen RevPiCore 3+ mit Profibus Gateway, welche über die piBridge (piright) miteinander gekoppelt sind. Grundsätzlich funktioniert alles problemlos, allerdings trat bei mir jetzt schon zweimal (immer jeweils nach einem Neustart) der hier beschriebene Fehler auf. Besonders ärgerlich sind die resets und das damit verbundenen 0 setzen des Prozessabbildes, was ja auch Sollwerte betrifft, die ich über den Profibus kommuniziere.
Das verwendete Revpi Kernel release ist mit 26.03.2021 aktuell, die Firmware-Version mit der V1.0 soll laut piTest -f die aktuellste sein, aber vermutlich noch nicht um den hier beschriebenen Bug bereinigt, oder?
Wenn ich das Profibus-Gateway also noch nicht um den Fehler bereinigen kann würde ich versuchen mich der Lösung mit dem netfilter hook auf die Gateway Frames mit dem ethertype 0x419c auseinander zu setzen. Kann das sporadische auftreten ggf. auch mit der von mir verwendeten UFW (firewall) zusammenhängen, die auf IPtables bzw. netfilter basiert?
Beste Grüße
Matthias
Who is online
Users browsing this forum: No registered users and 1 guest