Beckhoff "FPU invalid operation"

C

Crashy

Level-2
Beiträge
123
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Dringend ... Beckhoff "FPU invalid operation"

Hallo zusammen.


Diese Fehlermeldung bekomme ich seit 4 Tagen sporadisch:

TwinCAT PLC Lzs 1: Quelle: TCPLC.PlcTask; Zeitstempel: 14.02.2021 11:15:04 503 ms Meldung: 'PlcTask: FPU invalid operation' P1:0 P2:a8f11093 P3:a8f17a7f P4:21,
DriverStart: 0xa8f10000,
CodeStart: 0x84b7c000, CodeEnd: 0x84ba697e,
DataStart: 0xafe00000,
Offset: 0x24395093
Stack: 0x84ba6217<-0x84ba181f<-0x84b9f585<-0xa8f23a6d
Version: v2.11.2111


Die Runtime wird dann gestoppt.
Dachte erst, dass es mit meinen letzten Erweiterung zu tun hat und habe diese dann rückgängig gemacht.
Aber danach kam der Fehler immer noch.

Kann mir einer sagen, was für ein Problem ich habe ?
Brauche dringend eine Lösung, da ich unter der Woche immer unterwegs bin und nicht mitbekomme, wenn das passiert.
Danke.
 
Zuletzt bearbeitet:
Was mir gerade noch aufgefallen ist, dass es jeden Tag zur selben Zeit passiert, nämlich um 11:15.
Weitere Fehlereinträge sind:

TwinCAT PLC Lzs 1: Quelle: TCPLC.PlcAuxTask; Zeitstempel: 13.02.2021 11:15:45 629 ms Meldung: 'CPlcLzs: DbgWriteCallStack' POURef: 1969, LineRef: 17, Depth: 2


TwinCAT PLC Lzs 1: Quelle: TCPLC.PlcAuxTask; Zeitstempel: 13.02.2021 11:15:45 629 ms Meldung: 'CPlcLzs: DbgWriteCallStack' POURef: 1980, LineRef: 137, Depth: 1


TwinCAT PLC Lzs 1: Quelle: TCPLC.PlcAuxTask; Zeitstempel: 13.02.2021 11:15:45 629 ms Meldung: 'CPlcLzs: DbgWriteCallStack' POURef: 2003, LineRef: 182, Depth: 0
 
Zuviel Werbung?
-> Hier kostenlos registrieren
TwinCAT PLC Lzs 1: Quelle: TCPLC.PlcTask; Zeitstempel: 14.02.2021 11:15:04 503 ms Meldung: 'PlcTask: FPU invalid operation' P1:0 P2:a8f11093 P3:a8f17a7f P4:21,
DriverStart: 0xa8f10000,
CodeStart: 0x84b7c000, CodeEnd: 0x84ba697e,
DataStart: 0xafe00000,
Offset: 0x24395093
Stack: 0x84ba6217<-0x84ba181f<-0x84b9f585<-0xa8f23a6d
Version: v2.11.2111
Zum Vergrößern anklicken....


Gibt es denn zeitgesteuerte Funktionen, Zeitsynchronisation oder ähnliches?
Hast du schon mal potentielle Stellen gesucht, wo u.U. durch 0 dividiert wird?
 
Die System-FBs um das zu prüfen sind leider in keiner meiner Bibliotheken.
Ja, es gibt eine Zeitsynchronisationen. Ich hole alle 5s die Systemzeit vom PC. Das hat aber jahrelang funktioniert.
Zeitgesteuerte Funktionen gibt es auch, Licht und Jalousien. Aber auch das hat jahrelang funktioniert.
Die einzige zeitgesteuerte Funktion zu diesem Zeitpunkt wäre um 11Uhr der Funktionscheck der Jalousien, ob die Magnetkontakte noch funktionieren. Aber das hat auch schon längere zeit so funktioniert.

Ist ja auch erst am 11.2. erstmal aufgetreten. Zu dem Zeitpunkt hatte ich einen Wetter-FB integrieren wollen.
 
Hallo Crashy,
welchen Status hat denn deine Steuerung dann? Normalerweise ist ein Login noch möglich und anschließend wird versucht an die mögliche "Verursacherstelle" zu springen, wenn es nicht gerade in Libs verbaut ist. Andere Idee wäre einmal dein Log mit der tpy Datei zu vergleichen und den genannten Nummern 'POURef' der Meldungen vom 'CPlcLzs: DbgWriteCallStack' zu suchen. Vielleicht ein Hinweis zu den betroffenen POUs.

Viele Grüße
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi.
Die Runtime ist dann auf Stop, lässt sich auch nicht starten.
Mache ich einen Restart ist der PC voll ausgelastet und reagiert auf keine Eingabe. Danach kann man wieder starten.
Mir ist noch nicht aufgefallen, dass er dann an eine bestimmte Stelle springt, müsste ich mal testen.
Passiert halt zu einer bescheidenen Zeit und ich könnte nur abends per TeamViewer drauf.

Gruß Thorsten
 
Der häufigste Grund für solche Fehler bei mir war "division by zero". Darum habe ich mir frühzeitig angewöhnt vor Divisionen immer den Divisor auf 0 zu prüfen und einen Ersatzwert bereitzustellen. Außerdem sollte man vor indirekten Arrayzugriffen den Index im Blick behalten. Bei TC2 passiert da zwar nichts weiter, als das der Zeiger in fremde Speicherbereiche greift (Was auch heftige Auswirkungen haben kann), bei TC3 geht die RT aber auch in Stop.

Die Entwicklungsumgebung springt nach dem Einloggen zur verusachenden Stelle (versucht es, wenn im eigenen Quellcode). Ein Startversuch wird immer scheitern, weil die Ursache ja fortbesteht.

Wenn Du nach einem Neustart ein massives Auslastungsproblem hast, könnte die SPS in einer Endlosschleife gefangen sein? Ich hatte das auch schon mal, als ich bei TC3 (unbeabsichtigt) extrem oft Werte in die NC geschrieben hatte. Das fand die NC wohl nicht so toll. Und das obwohl die SPS das asynchron schrieb. Ich habe Wochen gesucht.
 
Es gibt ja Prüfbausteine, die in der Standardbibliothek enthalten sein sollen, sind sie bei mir aber nicht.
Müsste mir also was Eigenes schreiben.
In meinen Arrays sollten keine Probleme sein, die laufen seit Oktober schon.
Evtl. bei den Modbus-Bausteinen, da beim Einloggen ein Hinweis dazu kommt, dass sie nicht gefunden werden konnten, kann aber weiterhin meine Wechselrichter auslesen.

Gruß Thorsten
 
Wenn beim Einloggen der Hinweis kommt, dass irgendwelcher Bibliotheksquellcode nicht gefunden wurde, dann ist das genau der Versuch der Entwicklungsumgebung zum Stop-verursachenden Quellcode zu springen. Offensichtlich ist die Modbus-Bibliothek unsauber programmiert. Wenn Du den Quellcode nicht hast, bleibt Dir nur, die Eingangsparameter beim Aufruf so zu halten, das da keine ungültigen oder Bug-verusachenden Werte vorkommen.
 
Mal ganz allgemein

FPU = FloatingPointUnit und somit der Mathe-Prozessor auf dem Chip. Der hat mit manchen Operationen verständlicherweise Probleme.

Klassiker sind Divisionen durch 0 aber auch wenn du eine negative Wurzel rechen würdest o.ä. gibt es die gleiche Meldung.

Laut deinem Eventlogger kann man noch sagen dass der Fehler auf der Hierarchie "Main->FB1()" liegt. Das kann man aus "Depth=2" herauslesen.
Wenn es auftritt und die TwinCAT Ikone gelb ist kannst du online zur entsprechenden Codestelle springen.
Solltest du eine 4024.x haben kann man mit etwas Glück das auch noch später im Nachgang über den CoreDump realisieren.

Guga
 
Wenn Du sagst, dass der Chip in der Ursache liegen könnte, wäre ein Hardwarefehler auch möglich? Habe nämlich seit etwa 2 Monaten das Problem, dass er sich beim Übersetzen kurzzeitig weghängt. Es dauert dann etwa 30s bis die Meldung kommt, ob ich die Änderungen übernehmen möchte. Das Statusfenster zeigt dann "keine Rückmeldung" an.
Erst wenn ich den PC einmal neu starte ist alles für eine gewisse Zeit wieder in Ordnung.
 
Zuletzt bearbeitet:
@Crashy:

Da es TC2 ist: Schau mal in die *.tpy-Datei und suche dort nach <CodeIndex>1969</CodeIndex>.
Knapp darüber sollte der POU-Name der dir das Problem macht aufgeführt sein.

Dass das Teil einige Zeit braucht kann schon mal vorkommen - speziell wenn es ausgelastet ist. Das die HW ein Problem glaube ich nicht.
Prinzipiell bei solchen Themen bin ich ein Fan von "Alles bereinigen" in der SPS.

Guga
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hardware ausschließen würde ich aber nicht. Jedoch wenn es seit 2 Monaten auftritt, würde ich schon eher fragen was wurde alles verändert seitdem? Casts, Math,... Operationen mit Floats umfangreich hinzugefügt?
 
So, ich habe mal eben von unterwegs aus zugegriffen und da war natürlich wieder der Fehler.
Beim ersten Klick auf die Meldung springt er in einen Programmteil, in dem ich einen FB für den Sonnenauf- bzw. -untergang hinzugefügt hatte. Der ist jetzt raus.
Dann habe ich mal alles bereinigt und gesehen, dass meine Bausteinindizes zu 98% genutzt sind, also werde ich von 2048 mal auf 4096 erhöhen.
Und zum Fehler mit dem Modbus beim Übersetzen diese Meldung:
Fehler_Modbus.jpg

Hatte dann in der TPY auch mal geschaut, und 2 Nummern konnte ich wiederfinden. Die eine verweist auf mein Hauptprogramm mit den einzelnen Aufrufen und die andere auf das Programm Wetter bzgl. der Sonne.

Mal sehen, was morgen passiert.

Danke schon mal.
 
Aus welchen Lib sind denn diese Bausteine? Eine externe die auf Firmwarefunktionen zugreift die nicht vorhanden sind...?
 
Das kann man ja machen, wenn man möchte. Allerdings scheint hier aber auf Bausteine verwiesen zu werden "FB_Modbus_TcpOpen, ..Close, ...", die der Compiler nicht auflösen kann und als "extern" erwartet.
 

Similar threads

P
PLCTask: FPU Zero Divide
Antworten
8
Aufrufe
4K
pirattt85
P
Zurück
Oben