TwinSAFE - Not-Aus wenn Breakpoint im Debug-Modus erreicht wird

[twincatter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Newsgroup,

Ich habe festgestellt (und meine das auch schon einmal gehört zu haben), daß in Zusammenhang mit TwinSAFE (EL6900) immer dann ein NOT-AUS ausgelöst wird, wenn das SPS-Programm debuggt wird und ein Breakpoint erreicht wird.
Dies passiert (glaube ich) weil die SPS in diesem Fall nicht mehr mit der TwinSAFE-Klemme kommunizieren kann, weil das Programm auf dem Breakpoint 'steht'.

Könnt Ihr dieses Verhalten bestätigen?
Mache ich vielleicht noch etwas falsch?
Wie handhabt Ihr das?

Das Verhalten würde doch bedeuten daß ich im Prinzip nicht mehr debuggt werden darf wenn die Anlage nicht in den NOT-AUS gehen soll.


Ist die Lösung vielleicht einen eigenen Task anzulegen oder sogar eine weitere SPS-Runtime zu verwenden?




Ich hoffe auf Antworten, Michael

 

[trinitaucher]

Ich habe festgestellt (und meine das auch schon einmal gehört zu haben), daß in Zusammenhang mit TwinSAFE (EL6900) immer dann ein NOT-AUS ausgelöst wird, wenn das SPS-Programm debuggt wird und ein Breakpoint erreicht wird.
Dies passiert (glaube ich) weil die SPS in diesem Fall nicht mehr mit der TwinSAFE-Klemme kommunizieren kann, weil das Programm auf dem Breakpoint 'steht'.

Könnt Ihr dieses Verhalten bestätigen?
Mache ich vielleicht noch etwas falsch?
Wie handhabt Ihr das?

Das Verhalten würde doch bedeuten daß ich im Prinzip nicht mehr debuggt werden darf wenn die Anlage nicht in den NOT-AUS gehen soll.

Das beschrieben Verhalten ist korrekt. Nach einem Breakpoint erfolgt kein Feldbusupdate mehr (weil der am Ende eines jeden PLC-Zyklus stattfindet).
=> Also der ganze Bus steht.
Kein Update auf dem Bus bedeutet der Watchdog der Ausgangsklemmen (und auch der Safety-Klemmen) schlägt zu, woraufhin alle Klemmen in den definierten Stop-Zustand, bzw. die Safety-Klemmen in den sicheren Zustand gehen.

Man debuggt eine Maschine nicht mit Breakpoints :sm10:

Wofür braucht man Breakpoints?

 

[RobiHerb]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man debuggt eine Maschine nicht mit Breakpoints :sm10:

Wofür braucht man Breakpoints?

Manchmal geht es halt nicht ohne, oder sind mir da echte Wunder entgangen?

Das Problem besteht leider auch in Verbundsystemen mehrerer SPS (z.B. über CAN verbunden mit Heartbeat Überwachung oder NodeGuarding).

Aber wenn es andere Lösungen gibt, immer her damit!

 

[twincatter]

Hallo trinitaucher,

erst einmal vielen Dank für Deine Antwort.
Immerhin weiss ich jetzt dass das Verhalten korrekt ist.

Ich habe die TwinSAFE-Klemmen erst heute in Betrieb genommen (mein erstes Projekt mit TwinSAFE und überhaupt mein erstes Maschinenprojekt).
Ohne die TwinSAFE-Klemmen konnte ich das Projekt schön debuggen, I/Os und MotionControl hat einwandfrei funktioniert.
"Man debuggt eine Maschine nicht mit Breakpoints :sm10:"

OK - debuggen einer Maschine ist nicht gut, aber welche Alternative schlägst Du vor?

Alles im Vorfeld durchzusimulieren, auf die Maschine zu laden, und dann funktioniert alles auf Anhieb scheint mir kaum realistisch.

Bin sehr interessiert wie das Programmierer mit viel Erfahrung handhaben. Bin gerne bereit dazuzulernen.

Danke und ein schönes Wochenende, Michael

 

[StructuredTrash]

Breakpoints am lebenden Objekt sind wirklich zu gefährlich, die Maschine könnte den Begriff zu wörtlich nehmen.
Wenn eine komplexe Verknüpfung oder Berechnung nicht das erwartete Ergebnis bringt und ich einfach nicht dahinter komme, schreibe ich zeitweilig Zwischenergebnisse auf Hilfsvariablen, um den Vorgang besser beobachten zu können. Bei Ablaufsteuerungen sehe ich grundsätzlich einen Einzelschrittbetrieb vor, um die Bewegungen der Maschine einzeln ausführen zu können, bevor ich den ersten Automatikzyklus starte.

 

[trinitaucher]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK - debuggen einer Maschine ist nicht gut, aber welche Alternative schlägst Du vor?

Alles im Vorfeld durchzusimulieren, auf die Maschine zu laden, und dann funktioniert alles auf Anhieb scheint mir kaum realistisch.

Manchmal geht es halt nicht ohne, oder sind mir da echte Wunder entgangen?

Im Büro kann man natürlich machen was man will, aber an der Maschine sind Breakpoints für meine Begriffe ein No-Go.

Das Wunder zum Anschauen von Zuständen im Programm heißt z. B. "Scope View" und gibt's schon seit Ewigkeiten.

Oder den Tipp von StructuredTrash nutzen:

Wenn eine komplexe Verknüpfung oder Berechnung nicht das erwartete Ergebnis bringt und ich einfach nicht dahinter komme, schreibe ich zeitweilig Zwischenergebnisse auf Hilfsvariablen, um den Vorgang besser beobachten zu können. Bei Ablaufsteuerungen sehe ich grundsätzlich einen Einzelschrittbetrieb vor, um die Bewegungen der Maschine einzeln ausführen zu können, bevor ich den ersten Automatikzyklus starte.

Seit TwinCAT braucht man sich um Speicherplatz ja eigentlich keine großen Gedanken mehr zu machen.

 

[RobiHerb]

Im Büro kann man natürlich machen was man will, aber an der Maschine sind Breakpoints für meine Begriffe ein No-Go.

....

Auf die reale Maschine zu gehen ist natürlich gefährlich, wenn man Breakpoints setzt. Aber selbst da ist es manchmal wohl unumgänglich, da steht dann immer einer bereit, den Notaus zu betätigen.

Aber bevor es soweit ist, testen wir immer am Modell (hier ein Bild eines Rettungsbühnen Modells mit 6 Intercontrol Digsy SPS und 2 Bedienständen mit 2 Visu Rechnern).

.

 

[Neals]

Hallo Leute,

man kann diesen Effekt umgehen, indem man eine weitere Task anlegt:

Einfach im SystemManager eine Task anlegen (System / Additional Task / Rechtsklick / Append Task...).
Diese Task dann mit Autostart konfigurieren, ein paar I/O Variablen anlegen und diese mit Klemmen verknüpfen.
Dann triggert diese Task den Bus weiterhin, auch sollte die PLC stehen durch einen Breakpoint oder eine einfaches Stop.

Gruß, Neals

 

[twincatter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Neals,

vielen Dank für diese Informationen.
Ich werde dies gleich morgen ausprobieren!

Natürlich muss sorgfälltigst mit Breakpoints an einer laufenden Maschine umgegangen werden!

Danke, Michael

 

[Neals]

Ok, ganz so einfach war es doch nicht...

Ich musste eine zweite Laufzeit und darin die TwinSAFE Variablen anlegen.
Dann im SystemManager als erstes alles mit der zweiten Laufzeit (TwinSAFE.tpy) verknüpfen, danach mit der ersten Laufzeit anfangen.
Dadurch habe ich zwei komplett seperate Frames (0 = Standard 10ms, 1 = TwinSAFE 2ms) und wenn ich die erste Laufzeit stoppe, bleibt die zweite Laufzeit und TwinSAFE aktiv.

dq_SAFE_Run:= TRUE;

tpErrAck(
    IN:= bReset
        AND di_SAFE_ComErr,
    PT:= T#100ms);

dq_SAFE_ErrAck:= tpErrAck.Q;

tpReset(
    IN:= bReset,
    PT:= T#200ms);

dq_SAFE_Reset:= tpReset.Q;

bReset:= FALSE;

 

[twincatter]

Hallo Neals,

danke für diese weiteren Informationen.

P.S. war heute nicht bei der Arbeit - stattdessen in der Autowerksatt . Werde Deinen Vorschlag somit morgen ausprobieren.

Danke, Michael

 

[twincatter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

zum Anatz mit der zweiten Laufzeit für die SPS habe ich noch (mindestens) eine Frage.

Wie kann eine Kommunikation zwischen den zwei Laufzeiten realisiert werden? Ich habe diesbezüglich noch keine Erfahrung und wäre für Tips dankbar.

Grüße, Michael

 

[MarkusP]

Zum Beispiel über Netzwerkvariablen. Wenn Du flexibler (aber nicht mehr echtzeitfähig) sein willst, kannst Du auch
ADS READ bzw. ADS WRITE verwenden. Wir machen beides.

LG Markus

 

[twincatter]

Hallo Markus,

ich habe die benötigten Variablen im Systemmanager miteinander verknüpft.
Das war am Einfachsten und scheint zu funktionieren.
Mit ADS READ/WRITE habe ich es nicht hin bekommen.

Grüße vom Bodensee, Michael

 

[MarkusP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gute Lösung, was war das Problem bei ADS? Dass die Laufzeitsysteme unterschiedliche ADS-Ports haben weißt Du?
Über den Systemmanager hast Du den Nachteil, dass bei nachträglichen Änderungen das System neu aktiviert werden musst,
das kann mit ADS umgangen werden. (Steuerung muss nicht gestoppt werden)

Schönen Abend!