TIA S7-1500 Problem mit der Zykluszeit bei beim Schließen des Sicherheitskreises

[mmm_ams]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
ich habe ein Problem mit der Zykluszeit an einer Anlage. Tia17, mit 1515F SPS. Generell liegt die Zykluszeit bei ca. 40 ms, was in Ordnung ist. Allerdings steigt die Zykluszeit beim quittieren des Sicherheitskreises (Schutztür) kurz auf über 250 ms, was zu einem CPU-Stopp führt. Ich habe die max Zykluszeit vorübergehend erhöht, was natürlich keine Dauerlösung ist.
Hat jemand Erfahrung mit dem Problem gemacht?
Danke und grüße

 

[Elektrikus]

Mir hat ein gesamt Laden des Programs tatsächlich schon mal geholfen, nach dem ich eine CPU tauschen musste hatte ich das gleiche Problem mit der Zykluszeit. Nach dem erneuten Laden hat es funktioniert. Allerdings war es eine S7-400.

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du im Sicherheitsprogramm irgendwas nur bedingt aufgerufen? Normal geht das garnicht so ohne. Oder rufst du im Normalprogramm irgendwas bedingt auf?

 

[NBerger]

Ist Motion-Control im Projekt?
Wenn Ja:
- Wieviele Achsen?
- Welcher "Servo-Takt" wenn IRT-Kommunikation aktiv ist (Telegramm 5 ...)

 

[mmm_ams]

Hast du im Sicherheitsprogramm irgendwas nur bedingt aufgerufen? Normal geht das garnicht so ohne. Oder rufst du im Normalprogramm irgendwas bedingt auf?

Nein. Bedingte Aufrufe vermeide ich allgemein wegen Schwankung der Zykluszeit

 

[mmm_ams]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist Motion-Control im Projekt?
Wenn Ja:
- Wieviele Achsen?
- Welcher "Servo-Takt" wenn IRT-Kommunikation aktiv ist (Telegramm 5 ...)

Ich habe S120 mit 2 Achsen, Telegramme 30 und 110. MC-Servo wird zyklisch aufgerufen mit 4 ms Zyklus. Das sind alle die jetzigen Einstellungen im Projekt, wobei die S120 CU und Leistungsteile bereits am Netz sind aber sie sind bis jetzt noch nicht im betrieb (noch nicht konfiguriert, da noch die Motoren fehlen).

 

[Ralle]

Wenn der Stop kommt, kannst du dann zu der Stelle ijm Code springen, an der gestoppt wird?
Ich habe viele Servos in meinem derzeitigen Projekt, ebenfalls mit Telegramm 30, da kann ich so etwas nicht bestätigen.
Wo ich auch extrem lange Zykluszeiten sah, war beim ersten Hochlauf der SPS, wenn die Servos noch nicht korrekt eingegleidert waren.
Im Betrieb nach dem Hochlauf hatte ich da noch keine so großen Schwankungen.

 

[NBerger]

2 Achsen bei 4ms sollten jetzt mal keine "extreme" Last sein.
Irgend was ist da aber faul...
Wie hoch steht denn das Safety-Intervall.

 

[mmm_ams]

Zuviel Werbung?
-> Hier kostenlos registrieren

2 Achsen bei 4ms sollten jetzt mal keine "extreme" Last sein.
Irgend was ist da aber faul...
Wie hoch steht denn das Safety-Intervall.

Es liegt offensichtlich am Safety-Programm. Zum einen passiert der Sprung bei Quittierung des Sicherheitskreises (Freigabe der letzten Schutztür), wo dann die ganzen Abgänge freigegeben werden, zum anderen bekomme ich manchmal die Warnung, das die Zykluszeit des F-Programm zu hoch ist.
Kann man die Zykluszeit vom F-Programm genau messen? Ich glaube die Anweisung "Runtime" funktioniert nur in OB1, oder?

 

[mmm_ams]

2 Achsen bei 4ms sollten jetzt mal keine "extreme" Last sein.
Irgend was ist da aber faul...
Wie hoch steht denn das Safety-Intervall.

Also habe vergessen zu sagen, die Safety-Zyklus ist 100 ms

 

[TP-Inc]

Kannst/darfst du dein Sicherheitsprogramm als Screenshot posten?

 

[mmm_ams]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kannst/darfst du dein Sicherheitsprogramm als Screenshot posten?

Das meinst du?

 

[TP-Inc]

Nein, von der Logik

 

[NBerger]

OK...
Safetyänderungen sollten immer wohl überlegt sein!!!

Eine Variante wäre die Aufrufpriorität zu ändern. Bis 15 kann der Task durch Kommunikation unterbrochen werden, oberhalb nicht.
Ich setze ihn gerne auf 22, MC-Servo auf 26 und MC_Interpolator auf 24 wenn vorhanden.
Habe dann die Zykluszeiterhöhung durch Kommunikation meist auf 50% stehen.

Egal was du machst oder versuchst, es wird immer das Verhalten der Anlage im Detail ändern.
Kritisch zu betachten ist auf jeden Fall das Safety.

 

[Oberchefe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Frage wäre eher wie die Alarme generell hier gehandhabt werden?

 

[rostiger Nagel]

Kann man die Zykluszeit vom F-Programm genau messen? Ich glaube die Anweisung "Runtime" funktioniert nur in OB1, oder?

Du kannst Sie auslesen.

    REGION Safety
        //Bausteinaufruf
        #tmpRetValRtInfo := RT_INFO(MODE := 1,
                                    OB := #SAFETY,
                                    INFO := #tmpRtInfo);
        
        //Zeit in µs wandeln
        "008-GDB".Zykluszeit.Act.Safety := LTIME_TO_DINT(#tmpRtInfo) / 1000;
    END_REGION ;

 

[mmm_ams]

Nein, von der Logik

Schwierig. Das Programm an sich ist groß mit mehreren miltiinstanzierten Bausteinen und hierarchischer Struktur

 

[mmm_ams]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK...
Safetyänderungen sollten immer wohl überlegt sein!!!

Eine Variante wäre die Aufrufpriorität zu ändern. Bis 15 kann der Task durch Kommunikation unterbrochen werden, oberhalb nicht.
Ich setze ihn gerne auf 22, MC-Servo auf 26 und MC_Interpolator auf 24 wenn vorhanden.
Habe dann die Zykluszeiterhöhung durch Kommunikation meist auf 50% stehen.

Egal was du machst oder versuchst, es wird immer das Verhalten der Anlage im Detail ändern.
Kritisch zu betachten ist auf jeden Fall das Safety.

Dein Ansatz gefällt mir grundsätzlich. Wobei in meiner Anlage gibt es keine zeitkritischen Applikationen. Deswegen ist eine extrem kurze Zykluszeit des F-Programms nicht besonders wichtig, sondern eine relativ stabile Zykluszeit. Vielleicht mach die Unterbrechung durch Kommunikation etwas aus. Muss nochmal kontrollieren.

 

[Oberchefe]

Was für ein Prinzip wird für die Alarme verwendet?

 

[mmm_ams]

Was für ein Prinzip wird für die Alarme verwendet?

Prodiag