TIA Zykluszeitüberschreitung CPU 1515F 2-PN

[baj]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen, ich habe bei meiner Steuerung ein paar kleinere Änderungen im Sicherheitsprogramm gemacht(4 zusätzliche Estop1 und 3 Schutztürenauswertungen). Das funktioniert soweit auch problemlos. Sobald aber die Safety-Kommunikation mit der Partner-CPU (1518F-4PN/DP) läuft, erhöht sich die Zykluszeit schlagartig von 15 auf über 600ms, die CPU geht in den Stop-Zustand und der OB80 wird angefordert. Beide Steuerungen liefen vorher Problemlos mit der gleichen Safety-Kommunikation. Erst seit ich das Sicherheitsprogramm geladen, und die F-Bausteine wiedereingegliedert habe, kommt es zur Zykluszeitüberschreitung. Die Instanz-DBs habe ich alle nur ein mal verwendet und die Ein- und Ausgangsaddressen des Kopplers werden auch nicht überschrieben. Auch nicht indirekt mittels BLKMOV Hardware und Software können fehlerfrei übersetzt werden. An der Hardwarekofiguration hat sich nichts geändert. Kann mir hier jemand weiterhelfen?

 

[Peter Wahlen]

War dein Ursprungsprogrammstand gleich mit dem Onlinestand?
Was passiert, wenn du das alte Programm wieder in die SPS lädts (also ohne deine Änderungen)? Funktionierts dann? Wenn ja, wirst du einen Fehler bei deiner Programmänderung haben.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sobald aber die Safety-Kommunikation mit der Partner-CPU (1518F-4PN/DP) läuft, erhöht sich die Zykluszeit schlagartig von 15 auf über 600ms,

Haben sich denn Datenbereiche durch deine Änderung verschoben? Wenn ja, würde das auf der Partner SPS angepasst?

 

[Big_Rob_Baan]

Ich habe gerade ein ähnliches Problem. Ich habe in einem Programm einen Organisationsbaustein, in dem hauptsächlich PID Regler vorhanden waren, erweitert. Im Programm sollten meiner Meinung nach keine Fehler sein, weil alle Programmbausteine geladen werden konnten. Es wird mir allerdings angezeigt, das die CPU nicht starten kann. Folgende Fehlermeldung bzgl. "Zyklusüberschreitung wird ausgegeben.

Ich habe bereits die Aufrufzeit des OBs varriert vom Minimum bis hin zum Maximum und es änderte sich nichts.

Lieber Gruß

 

[PN/DP]

Hast Du eine Schleife programmiert? Die zu lange oder gar endlos läuft?

 

[Big_Rob_Baan]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meinst du zB. eine For schleife?
Ja, dass habe ich sie umfasst einen Array mit 120 Real Variablen.
Diese habe ich gerade gelöscht und der Fehler tritt immernoch auf.

 

[magier]

Was steht denn im OB32 ? oder wie häufig wird dieser aufgerufen ?

Mfg

 

[Big_Rob_Baan]

Den Fehler im OB32 habe ich gerade ausgebügelt. Es handelte sich um eine while... Do Beziehung, die ich durch eine IF Then Beziehung ersetzt habe. Dann funktioniert es.
Allerdings ist ein anderer Fehler aufgetaucht. "Bereichslängenfehler beim Lesen" heißt es. Ich gucke aber erstmal ob es dazu schon einen Beitrag gibt.

Danke für die Ideen
Rob

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den Fehler im OB32 habe ich gerade ausgebügelt. Es handelte sich um eine while... Do Beziehung, die ich durch eine IF Then Beziehung ersetzt habe. Dann funktioniert es.
Allerdings ist ein anderer Fehler aufgetaucht. "Bereichslängenfehler beim Lesen" heißt es. Ich gucke aber erstmal ob es dazu schon einen Beitrag gibt.

Danke für die Ideen
Rob

Taucht auf, wenn versucht wird zB mit einem Zeiger ein Fach zu lesen welches nicht existiert (Arraygrenze überschritten)

 

[Big_Rob_Baan]

Meinst du einen Zeiger im HMI? Ich verstehe nicht ganz worauf du hinaus willst, bzw. vielleicht ist dies nur ein Sonderfall deswegen hier mal der die aktuelle Fehlermeldung.
Ich hatte die Vermutung das mein Datenbaustein zu groß ist mit 1172 in der Spalte für Offset, weil 3 große Arrays darin enthalten sind. Oder sind diese Dimensionen üblich. Was wird sonst bemängelt?

 

[DCDCDC]

Beispiel:

Array[0..9] of Bool

If Array[10].Bool TRUE

In einer For Schleife dann mit Zeiger i hat Wert 10

Und schon hast du deinen Bereichslängenfehler, weil der Zeiger auf das zehnte Fach zeigt. welches aber in dem Bereich nicht existiert.

Deswegen immer bei Schleifen Arraygrenzen überprüfen damit dass nicht überläuft.

 

[Oberchefe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du ein wenig runter scrollst kannst du auf den Button klicken und zu der fehlerhaften Stelle springen.

 

[Heinileini]

...
In einer For Schleife dann mit Zeiger i hat Wert 10

Und schon hast du deinen Bereichslängenfehler, weil der Zeiger auf das zehnte Fach zeigt. welches aber in dem Bereich nicht existiert.

Um Missverständnissen vorzubeugen:
Nein, der Zeiger bzw. Index mit dem Inhalt 10 zeigt NICHT unbedingt auf das zehnte Fach/Element, sondern auf das Fach/Element mit der Nr. 10.
Beide Aussagen sind nämlich nur dann identisch, wenn das Array mit der Fach- bzw. Element-Nr 1 beginnt.

Edit:

Taucht auf, wenn versucht wird zB mit einem Zeiger ein Fach zu lesen welches nicht existiert (Arraygrenze überschritten)

Ebenfalls um Missverständnissen vorzubeugen:
Obere ArrayGrenze überschreiten ist "ungesund", aber auch ein Unterschreiten der unteren ArrayGrenze ist gleichermaßen "ungesund" und überschreitet den Bereich, den das Array belegt.

 

[baj]

Habe mein Problem gelöst. Es war die F-Zykluszeit. Die Zykluszeit vom Standardprogramm war ja ungefähr bei 15 bis 20 ms. Die F-Zykluszeit war auf 10 ms eingestellt und wurde dementsprechend zu oft aufgerufen. Seit ich die F-Zykluszeit auf 20 ms eingestellt habe läuft alles wieder ganz normal.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wofür brauchst du so ein schnelles F-Programm ?
50 ms Intervall wären auch noch vollkommen okay ...

 

[Cassandra]

Wofür brauchst du so ein schnelles F-Programm ?
50 ms Intervall wären auch noch vollkommen okay ...

Bei einer Anwendung mit Lichtgitter können 10ms entscheidend sein, ob du den vorgeschriebenen Mindestabstand noch einhalten kannst oder nicht. Zu der Laufzeit von dem Sicherheitsprogramm kommt ja noch die Reaktions-Zeit vom Sensor, Schaltorgan und Aktor hinzu!

Vor allem willst du nicht die Maschine umbauen, nur weil deine Sicherheits-SPS plötzlich 600ms anstatt 10ms benötigt…

 

[Larry Laffer]

Bei einer Anwendung mit Lichtgitter können 10ms entscheidend sein, ob du den vorgeschriebenen Mindestabstand noch einhalten kannst oder nicht. Zu der Laufzeit von dem Sicherheitsprogramm kommt ja noch die Reaktions-Zeit vom Sensor, Schaltorgan und Aktor hinzu!

Vor allem willst du nicht die Maschine umbauen, nur weil deine Sicherheits-SPS plötzlich 600ms anstatt 10ms benötigt…

Wenn es bei deiner Anwendung auf 10ms Reaktionszeit des F-Programms ankommen sollte dann würde ich sagen, dass da konzeptionell ganz böse etwas schief gelaufen ist. Bitte auch immer daran denken : wir sprechen hier nicht von einem Echtzeit-System ...

 

[Cassandra]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn es bei deiner Anwendung auf 10ms Reaktionszeit des F-Programms ankommen sollte dann würde ich sagen, dass da konzeptionell ganz böse etwas schief gelaufen ist. Bitte auch immer daran denken : wir sprechen hier nicht von einem Echtzeit-System ...

Wenn es üblich ist, dass in Verbindung mit Sicherheits-Steuerungen keine unmittelbaren Schalthandlungen in Echtzeit ausgelöst werden können, dann hab ich die Technik in der Tat falsch verstanden.

Beziehst du dich auf die neue Maschinenverordnung?
Die habe ich bisher nur schnell überflogen – leider noch nicht bis ins Detail gelesen…

Wird dort der neuen Sicherheits-KI eine „Schrecksekunde“ zugestanden?

 

[Larry Laffer]

Bei einer Anwendung mit Lichtgitter können 10ms entscheidend sein, ob du den vorgeschriebenen Mindestabstand noch einhalten kannst oder nicht.

Auf das Vorgenannte habe ich mich bezogen.
Wenn bei deiner Mindestabstands-Geschichte, wie von dir gepostet, die 10 ms Relevanz haben dann ist in dem ganzen Konzept der Wurm drin, weil :

Zu der Laufzeit von dem Sicherheitsprogramm kommt ja noch die Reaktions-Zeit vom Sensor, Schaltorgan und Aktor hinzu!

... und in diesem Teil können ganz schnell mal Vielfache von 10 ms +/- auftreten.
Aber bitte - du kannszt es ja so machen wie du meinst. Ich würde mich da niemals auf so dünnes Eis begeben.

Aber, by the way, nehmen wir mal an du hast einen Standard-Not-Stop-Schalter im Einsatz, so mit ganz normalen Kontakten, welche Diskrepanzzeit gestehst du dem normalerweise zu ? Und ... wie sieht das bei dir mit den Schaltkontakten von Sicherheits-LS-Auswertegeräten aus ? Diskrepanzzeit = 0 ?

 

[ducati]

Habe mein Problem gelöst. Es war die F-Zykluszeit. Die Zykluszeit vom Standardprogramm war ja ungefähr bei 15 bis 20 ms. Die F-Zykluszeit war auf 10 ms eingestellt und wurde dementsprechend zu oft aufgerufen. Seit ich die F-Zykluszeit auf 20 ms eingestellt habe läuft alles wieder ganz normal.

Die Diskussion ohne Hintergrundwissen ist doch müßig...
Was Cassandra sicherlich meint ist: man sollte nicht blindlings an der F-Zykluszeit (und am F-Programm) rumfummeln, ohne die Gesamthintergründe verstanden zu haben.
Bsp. Reaktionszeit von 150ms gefordert. Vor der Änderung warns 145ms jetzt sinds 155ms... Wer weiss das schon...
Ich würde mich mal der Warnung an den TE anschliessen!
Dass nach solch einer Änderung eine Neubewertung/Neuabnahme der Sicherheitsfunktionen notwendig ist, wie auch immer die im Detail aussieht sollte jedenfalls dem TE auch klar sein?