Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
ich arbeite aktuell mit CODESYS Control for PFC200 SL Version 3.5.13.0.
Das Verhalten beobachte ich bei beiden der zwei Varianten, die wir gerade zur Hand haben:
750-8206/040-000
750-8206/040-001
Dazu ist noch eine Klemme an der Steuerung:
750-1515/040-000 (8 DA)
Mein Programm läuft, die LEDs SYS, RUN, I/O und CAN sind gelb. Wenn ich dann den Betriebsartenschalter auf STOP stelle, geht RUN auf rot (was zu erwarten war). Dabei gehen alle Ausgänge aus (was ich nicht erwartet hätte). Stelle ich den Schalter wieder auf RUN, fängt I/O an rot zu blinken. Zwischen den Pausen blinkt die LED zuerst 9 mal und dann 5 mal. Laut Manual ist 9 ein CPU-Ausnahmefehler. Für das Argument 5 gibt es unter Fehlercode 9 keinen Eintrag.
Setze ich das Programm fort, funktioniert das Debuggen noch. Ich kann noch Breakpoints setzen und durchsteppen. Aber die Ausgänge sind weg. Nach einem Reset warm oder Reset kalt aus der CODESYS IDE läuft es wieder.
Wenn ich bei laufenden Programm in CODESYS über den Debugger auf STOP gehe, verhält sich das System genau so. Das größte Problem ist, dass dies auch bei Breakpoints auftritt. Sobald das Programm in einen Breakpoint läuft, geht alles aus. Ich habe auch schon im cbm die Runtime von e!RUNTIME auf none umgestellt. Das macht aber keinen Unterschied.
Desweiteren ist mir aufgefallen, dass CODESYS anscheinend abstürzt, wenn man mit dem Betriebsartenschalter einen Reset macht (Schalter für 2 s auf Reset und dann loslassen). In "top" wird "codesyscontrol. <defunct>" angezeigt. Dann hilft nur noch codesyscontrol neustarten mit</defunct>
Also diese Einstellung bewirkt zumindest, dass die Ausgänge nicht mehr ausgehen, wenn die Steuerung im STOP ist (per Schalter oder Debugger).
Jedoch besteht die Problematik weiterhin, sobald das Programm in einen Breakpoint läuft.
Übrigens habe ich zum Test ein ganz simples Programm aufgebaut. Es besteht nur aus einer Variablen und einer Zeile. Der Task führt das Programm alle 20 ms aus. Ein Byte wird inkrementiert und dieses ist auf die Ausgangsklemme gemappt.
Ist das so eine Art Software-Watchdog, der überwacht, dass die I/Os regelmäßig aktualisiert werden? Und wenn der Bustask hängt, wird alles ausgeschaltet?
Gerade noch rausgefunden, dass ein Task mit hoher Zykluszeit 200 bis 400 ms dazu führt, dass die Ausgänge zwischendurch ausgehen (die Ausgänge blinken quasi, I/O-Led leuchtet durchgehend grün). Bei einer Zykluszeit von 500 ms gehen die Ausgänge gar nicht erst an und die I/O-Led blinkt rot.
Ich habe das gleiche Programm nochmal in e!Cockpit getestet. Da gibt es diese Probleme nicht. Also
Das heißt aber nicht, dass wir nun e!Cockpit verwenden wollen
VG,
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ich würde empfehlen es wie folgt aufzusetzen:
1. du legst für den KBUS eine eigene Task an mit zweit höchster Priorität ( wenn man das so macht bleibt auch das Echtzeitverhalten der höchst Prioren Task erhalten)
2. SPS Einstellungen "always update" an
3. Verwendung aller KBUS Variablen nur in der KBUSTask Pou ( darauf peinlichst achten) - und mit Taskdeployment auch kontrollieren.
Dann sollte das funktionieren wie du es erwartest.
Eine Einschränkung hat es natürlich - diese Kbus Task kann man nicht einfach debuggen, dabei gehen wie du schon geschrieben hast die Ausgänge aus, da kein Update mehr stattfindet wenn du einen Brakepoint setzt.
Grüße
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
danke für den Tipp. Das funktioniert bisher sehr gut. Wir werden das so übernehmen.
Aber folgende Frage kommt trotzdem auf: Ist das ein Bug in CODESYS Control for PFC200 und könnte dieser in einer kommenden Version gefixt werden? Oder geht das nicht anders zu machen? Ich meine, mit der WAGO-Software läuft es ja wie erwartet.
Bei der vorgeschlagenen Lösung muss man durchaus ein paar Punkte beachten. KBUSTask könnte von MainTask unterbrochen werden. Wir haben nur 8 Ausgänge. Daher wird das Update atomar erfolgen. Aber falls man mehr hat oder die Ausgänge bitweise übertragt, könnte ein weiterer MainTask-Zyklus zwischen einen Durchlauf der KBUSTask kommen. Das dürfte eher unwahrscheinlich sein, wenn von der Task-Laufzeit ausreichend Puffer vorhanden ist, aber es ist möglich. Was auf alle Fälle auftritt, ist, dass die Ausgänge beim Debuggen sofort aktualisiert werden. Normalerweise werden ja geänderte Ausgänge erst am Ende der Task ins IO-Abbild übernommen. Da dieses Übernehmen nun aber in eine eigene Task ausgelagert wurde, findet dies auch statt während der MainTask im Breakpoint steht. Man müsste ein temporäres IO-Abbild, welches am Ende von MainTask ausgegeben wird nun manuell implementieren und dieses mit KBUSTask in das reale IO-Abbild schreiben.
Dennoch ist es eine gute Lösung, um die Exception zu verhindern.
VG,
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo Jan,
wie es genau in eCockpit realisiert ist weiß ich nicht.
Vermutlich macht Wago das KBUS Update in einer eigene Task die nicht über eCockpit konfiguriert wird.
Bei uns ist es ja so, dass du den PFC auch z.B ganz ohne KBUS betreiben könntest.
Die KBUS Update von irgend einer Task getriggert werden muss(IEC Task). Klar wenn du auf die Echtzeitanforderungen keinen Wert legst kann die natürlich auch gleich sein und die höchst priore Task.
Als einen Fehler sehen wir das so nicht, das ist "as designed" also durchaus so gewolt.
Ich denke aber es ist keine Einschräkung sondern eher felxibler. ( Klar man kann mehr falsch machen) wenn man es nicht beachtet.
Übrigens - wenn ich noch empfehlen darf, würde auf jedenfall Runtime >3.5SP12Patch1 auf PFC Seite verwenden, das es < 3.5SP12Patch1 probleme mit der Lizenzsierung gab ( sporadischer Lizenzverlust in seltenen Fällen) - du hattest irgendwo geschrieben du verwendest SP10...
Auch wenn du sagst ich will in CODESYS SP10 arbeiten - die Runtime auf PFC seite sollte aktuell sein.
Grüße
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ich arbeite aktuell mit CODESYS Control for PFC200 SL Version 3.5.13.0.
Das Verhalten beobachte ich bei beiden der zwei Varianten, die wir gerade zur Hand haben:
750-8206/040-000
750-8206/040-001
Dazu ist noch eine Klemme an der Steuerung:
750-1515/040-000 (8 DA)
Mein Programm läuft, die LEDs SYS, RUN, I/O und CAN sind gelb. Wenn ich dann den Betriebsartenschalter auf STOP stelle, geht RUN auf rot (was zu erwarten war). Dabei gehen alle Ausgänge aus (was ich nicht erwartet hätte). Stelle ich den Schalter wieder auf RUN, fängt I/O an rot zu blinken. Zwischen den Pausen blinkt die LED zuerst 9 mal und dann 5 mal. Laut Manual ist 9 ein CPU-Ausnahmefehler. Für das Argument 5 gibt es unter Fehlercode 9 keinen Eintrag.
Setze ich das Programm fort, funktioniert das Debuggen noch. Ich kann noch Breakpoints setzen und durchsteppen. Aber die Ausgänge sind weg. Nach einem Reset warm oder Reset kalt aus der CODESYS IDE läuft es wieder.
Wenn ich bei laufenden Programm in CODESYS über den Debugger auf STOP gehe, verhält sich das System genau so. Das größte Problem ist, dass dies auch bei Breakpoints auftritt. Sobald das Programm in einen Breakpoint läuft, geht alles aus. Ich habe auch schon im cbm die Runtime von e!RUNTIME auf none umgestellt. Das macht aber keinen Unterschied.
Desweiteren ist mir aufgefallen, dass CODESYS anscheinend abstürzt, wenn man mit dem Betriebsartenschalter einen Reset macht (Schalter für 2 s auf Reset und dann loslassen). In "top" wird "codesyscontrol. <defunct>" angezeigt. Dann hilft nur noch codesyscontrol neustarten mit</defunct>
oder halt die ganze Steuerung.
Das Problem beim Debuggen ist aber mein schwerwiegendstes Problem. Kann das sonst noch jemand bestätigen oder funktioniert das bei euch?
Die Version der Wago-Firmware ist 02.08.35(11).
Ich verwende noch CODESYS SP10 Patch 5, aber ein Test mit SP13 Patch 1 brachte das gleiche Ergebnis.
VG,
Jan
Hi,
kannst du mal den Haken bei "Update IO's while plc in Stop"
in den SPS Einstellungen setzen?
Grüße
Edwin
Hallo Edwin,
danke für deine Antwort.
Also diese Einstellung bewirkt zumindest, dass die Ausgänge nicht mehr ausgehen, wenn die Steuerung im STOP ist (per Schalter oder Debugger).
Jedoch besteht die Problematik weiterhin, sobald das Programm in einen Breakpoint läuft.
Übrigens habe ich zum Test ein ganz simples Programm aufgebaut. Es besteht nur aus einer Variablen und einer Zeile. Der Task führt das Programm alle 20 ms aus. Ein Byte wird inkrementiert und dieses ist auf die Ausgangsklemme gemappt.
Ist das so eine Art Software-Watchdog, der überwacht, dass die I/Os regelmäßig aktualisiert werden? Und wenn der Bustask hängt, wird alles ausgeschaltet?
Gerade noch rausgefunden, dass ein Task mit hoher Zykluszeit 200 bis 400 ms dazu führt, dass die Ausgänge zwischendurch ausgehen (die Ausgänge blinken quasi, I/O-Led leuchtet durchgehend grün). Bei einer Zykluszeit von 500 ms gehen die Ausgänge gar nicht erst an und die I/O-Led blinkt rot.
Ich habe das gleiche Programm nochmal in e!Cockpit getestet. Da gibt es diese Probleme nicht. Also
Das heißt aber nicht, dass wir nun e!Cockpit verwenden wollen
VG,
Jan
Hallo Jan,
ich würde empfehlen es wie folgt aufzusetzen:
1. du legst für den KBUS eine eigene Task an mit zweit höchster Priorität ( wenn man das so macht bleibt auch das Echtzeitverhalten der höchst Prioren Task erhalten)
2. SPS Einstellungen "always update" an
3. Verwendung aller KBUS Variablen nur in der KBUSTask Pou ( darauf peinlichst achten) - und mit Taskdeployment auch kontrollieren.
Dann sollte das funktionieren wie du es erwartest.
Eine Einschränkung hat es natürlich - diese Kbus Task kann man nicht einfach debuggen, dabei gehen wie du schon geschrieben hast die Ausgänge aus, da kein Update mehr stattfindet wenn du einen Brakepoint setzt.
Grüße
Edwin
Hallo Edwin,
danke für den Tipp. Das funktioniert bisher sehr gut. Wir werden das so übernehmen.
Aber folgende Frage kommt trotzdem auf: Ist das ein Bug in CODESYS Control for PFC200 und könnte dieser in einer kommenden Version gefixt werden? Oder geht das nicht anders zu machen? Ich meine, mit der WAGO-Software läuft es ja wie erwartet.
Bei der vorgeschlagenen Lösung muss man durchaus ein paar Punkte beachten. KBUSTask könnte von MainTask unterbrochen werden. Wir haben nur 8 Ausgänge. Daher wird das Update atomar erfolgen. Aber falls man mehr hat oder die Ausgänge bitweise übertragt, könnte ein weiterer MainTask-Zyklus zwischen einen Durchlauf der KBUSTask kommen. Das dürfte eher unwahrscheinlich sein, wenn von der Task-Laufzeit ausreichend Puffer vorhanden ist, aber es ist möglich. Was auf alle Fälle auftritt, ist, dass die Ausgänge beim Debuggen sofort aktualisiert werden. Normalerweise werden ja geänderte Ausgänge erst am Ende der Task ins IO-Abbild übernommen. Da dieses Übernehmen nun aber in eine eigene Task ausgelagert wurde, findet dies auch statt während der MainTask im Breakpoint steht. Man müsste ein temporäres IO-Abbild, welches am Ende von MainTask ausgegeben wird nun manuell implementieren und dieses mit KBUSTask in das reale IO-Abbild schreiben.
Dennoch ist es eine gute Lösung, um die Exception zu verhindern.
VG,
Jan
Hallo Jan,
wie es genau in eCockpit realisiert ist weiß ich nicht.
Vermutlich macht Wago das KBUS Update in einer eigene Task die nicht über eCockpit konfiguriert wird.
Bei uns ist es ja so, dass du den PFC auch z.B ganz ohne KBUS betreiben könntest.
Die KBUS Update von irgend einer Task getriggert werden muss(IEC Task). Klar wenn du auf die Echtzeitanforderungen keinen Wert legst kann die natürlich auch gleich sein und die höchst priore Task.
Als einen Fehler sehen wir das so nicht, das ist "as designed" also durchaus so gewolt.
Ich denke aber es ist keine Einschräkung sondern eher felxibler. ( Klar man kann mehr falsch machen) wenn man es nicht beachtet.
Übrigens - wenn ich noch empfehlen darf, würde auf jedenfall Runtime >3.5SP12Patch1 auf PFC Seite verwenden, das es < 3.5SP12Patch1 probleme mit der Lizenzsierung gab ( sporadischer Lizenzverlust in seltenen Fällen) - du hattest irgendwo geschrieben du verwendest SP10...
Auch wenn du sagst ich will in CODESYS SP10 arbeiten - die Runtime auf PFC seite sollte aktuell sein.
Grüße
Edwin