TIA IO-Link Teilnehmer arbeitet mit schnellerer CPU nicht mehr korrekt

[CL-391]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

vor wenigen Wochen stand an einem unserer Projekte der Austausch der CPU bevor.
Da die bereits vorhandene 1516F-3 PN/DP (6ES7 516-3FN02-0AB0) aufgrund von Taktsynchronen Servoachsen (IRT), Safety- und viel OPC-Kommunikation mit stark schwankender Zykluszeit (~12-90ms) zu kämpfen hatte, wurde sie gegen eine 1518F-4 PN/DP (6ES7 518-4FP00-0AB0) ausgetauscht. Die neue Zykluszeit bewegte sich trotz Schwankungen bei unter 2ms. Ziel erreicht. Zumindest kurz.

Nach Wieder-Inbetriebnahme aller Achsen und ersten Testläufen hat sich herausgestellt, dass sich diverse Endgeräte "komisch" verhielten. Im Detail ging es dabei um drei Festo Antriebsregler. Die Antriebsregler sind je an einer separaten ET200eco PN 4IO-L (6ES7 148-6JD00-0AB0) via IO-Link angeschlossen. Die ET200eco sind über PN mit der CPU verbunden. Die Kommunikation zwischen CPU und Antriebsregler erfolgt über Bausteine, die aus einer von Festo zum Download angebotenenen Bibliothek stammen. Diese verwenden im Endeffekt PEEK / POKE um IO-Daten auszutauschen.
Die Antriebsregler ließen sich nach dem Austausch der CPU nur noch sporadisch ansteuern. Durch setzen einer Mindest-Zykluszeit konnte das Problem wieder in den Griff bekommen werden. Mit einer Mindest-Zykluszeit von 5ms konnten deutlich weniger sporadische Ausfälle beobachtet werden, bei 10ms Mindest-Zykluszeit schließlich garkeine mehr.

Kann mir einer erklären was hier passiert ist? Die Mindest-Zykluszeit ist hier eigentlich nicht zielführend da wir mit dem Austausch der CPU an genau dieser Schraube drehen wollten. Durch die Verringerung der Zykluszeit der CPU haben wir uns eine Verkürzung der recht knapp kalkulierten Anlagen-Taktzeit erhofft da relativ lange Schrittketten je Anlagenzyklus beteiligt sind. Am Takt des PN bzw. des IO-Link solle sich ja trotz gesteigerter Rechenleistung der CPU nichts verändert haben, sodas jetzt auf einmal "zu viele" IO-Aktualisierungen zum Einbruch der Kommunikation des IO-Link Teilnehmers führen können? Oder liege ich hier falsch und die schnellere Zykluszeit beeinflusst doch etwas am IO-Link? Bitte klärt mich auf, ich bin ratlos

P.S.: Das Ganze spielte sich unter TIA V16 Upd.3 ab.

Vielen Dank vorab
Gruß Christian

 

[PN/DP]

Läuft Dein Programm multi-Tasking in verschiedenen zyklischen OB? Vielleicht ist die inter-Task Kommunikation nicht gut gelöst?

Harald

 

[CL-391]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Harald,

danke für die schnelle Antwort!

Das gesamte Haupt-Programm läuft ausschließlich im OB1. Es gibt natürlich weitere OBs (Diagnose, Interrupt, Startup, Safety, MC-Servo, etc.), die aber keine Überschneidungen mit dem Programmteil der Antriebsregler haben. Die genannten Antriebsregler laufen auch nicht über den MC-Servo, es handelt sich hier um einfache Schrittmotor-Regler. Die IO-Daten werden automatisch über das normale Prozessabbild aktualisiert.

Gruß Christian

 

[NBerger]

Hallo...,
a) meinst du wirklich IO-Link oder doch "Profinet-IO"
b) Festo arbeitet asynchron zu deinem Bus, das ist normal. Bei Zykluszeiten unter 5ms arbeiten die Festo-FU's nicht mehr richtig da Flanken auf Festoseite nicht mehr richtig erkannt werden.
Abhilfe (So mache ich das seit Jahren):
- Zeitgesteuerten OB anlegen mit dem gewünschten "Servotakt" (5-10ms).
- Im OB für jeden Antrieb ein Bit setzen (DB oder Merker)
- Den Antiebsbaustein nur aufrufen wenn dieses Bit gesetzt ist und mit dem Aufruf dieses Bit wieder ablöschen.

 

[CL-391]

Hallo @NBerger,

Ja ich meine wirklich IO-Link. Die Antriebsregler von Festo sind Geräte mit IO-Link-Anbindung (CMMO-ST-C5-1-LKP) und auch "nur" einfache Schrittmotorregler. Hier ist leider keine Möglichkeit auf direkte Anbindung ans PN-Netz gegeben, daher der Umweg über die ET200eco-Station (PN -> IO-Link).

Dass Festo-FU's asynchron arbeiten war mir so direkt nicht bewusst, klingt aber absolut logisch wenn man mal drüber nachdenkt. In der Regel warte ich nach dem schreiben von Signalen darauf, dass diese durch eine Rückmeldung in irgendeiner Form auch vom Kommunikationspartner quittiert / bestätigt wurden, aber ob das auch tiefer in den von Festo gelieferten Bausteinen so ist kann ich nicht sagen. Ich werde deinen Tipp in jedem Fall ausprobieren und hier eine Rückmeldung geben ob der Versuch erfolgreich war oder nicht!

Danke und Gruß Christian

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Erklärung mit den verloren Flanken sehe ich nicht ganz ein. Ich habe CMMO nicht oft im Einsatz gehabt, aber sehr viele CMMT. Die Programmierung von Festo scheint absolut sattelfest zu sein. Ich denke, dass man hier mit vernünftigen Handshakes alles zykluszeitunabhängig hinkriegenden kann. Ohne irgendwelche Krücken. Der Support bei Festo ist top (zumindest in Österreich). Am besten mal dort nachfragen.

 

[UDP]

Nutzen die Festobausteine intern den IO_Link_Device von Siemens? Falls ja, hast du weitere Teilnehmer, die mittels dieses Bausteins angesprochen werden? Intern arbeitet der mit WRREC/RDREC und hierbei kann es dazu kommen, dass die Aufträge nicht rechtzeitig abgearbeitet werden, weil die Ressourcen dazu nicht verfügbar sind, siehe:

https://support.industry.siemens.co...r-profibus-dp-bzw-profinet-io-?dti=0&lc=de-DE

Deine CPU sollte maximal 20 Aufträge gleichzeitig verarbeiten können, wenn hier mehr läuft (oder vielleicht auch in den Festobausteinen mehrfach angesprochen wird), kann niedrigere Zykluszeit auch dazu führen, dass hier einfach keine saubere Kommunikation mehr läuft.

 

[CL-391]

Nutzen die Festobausteine intern den IO_Link_Device von Siemens?(...)

@UDP nein, die (von mir verwendeten) Bausteine für die Antriebsregler nutzen ausschließlich PEEK bzw. POKE zur Kommunikation nach außen.

(...)Deine CPU sollte maximal 20 Aufträge gleichzeitig verarbeiten können(...)

WRREC oder RDREC werden laut Projektweiter Suche von verschiedenen Systembausteinen verwendet, davon ist aber keiner an der Kommunkation mit den Antriebsreglern beteiligt. In Summe sind allerdings deutlich mehr als 20 Instanzen von WRREC/RDREC bedingt durch einige andere Systembausteine vorhanden. Hier sollte ich in jedem Fall eine parallele Begrenzung schaffen. Danke für den Hinweis!

 

[CL-391]

Zuviel Werbung?
-> Hier kostenlos registrieren

(...)
- Zeitgesteuerten OB anlegen mit dem gewünschten "Servotakt" (5-10ms).
- Im OB für jeden Antrieb ein Bit setzen (DB oder Merker)
- Den Antiebsbaustein nur aufrufen wenn dieses Bit gesetzt ist und mit dem Aufruf dieses Bit wieder ablöschen.

Das hab ich gerade so umgesetzt, funktioniert nach ersten Tests jetzt auch ohne Mindest-Zykluszeit Fehlerfrei! Vielen Dank für deinen Tip!

Gruß Christian

 

[CL-391]

Nachdem mir das Thema keine Ruhe gelassen hat und ich es nicht verstanden habe, warum Teilnehmer am Bus trotz vernünftiger Handshakes Flanken übersehen, habe ich mich noch einmal damit auseinander gesetzt.

Es hat sich herausgestellt dass die ansteuernde Schrittkette nicht in jedem Fall einen sauberen Handshake zum Antriebsregler ausgeführt hat. In einigen Fällen kam es vor, dass das Bit zum Starten eines Positionierauftrags nach erreichen der Zielposition quittiert und im übernächsten Zyklus wieder gesetzt wurde. Rein SPS-Technisch war das Bit für mindestens einen Zyklus FALSE, der Antriebsregler bekam davon aufgrund der geringen Zykluszeit der schnelleren CPU aber nichts mehr mit. Die quittierung des auf FALSE gesetzten Anforderungsbits durch den Antriebsregler wurde dabei nicht beachtet.
Genau das habe ich ausgebügelt und siehe da - es funktioniert. Da muss ich die Signatur von @PN/DP zitieren:

Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

Fazit:
Wird der Handshake in jedem Fall sauber ausgeführt, dann klappts auch ohne Krücken oder zeitlich gesteuerte Bausteinaufrufe. Vielen Dank für eure hilfreichen Tips!

Gruß Christian

 

[NBerger]

Hast du vielleicht ein Codeschnipsel?

 

[blimaa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi

Ja das kann ich bestätigen, dass die CMMO relativ langsam sind. Vorallem auch beim Modus umschalten oder Start Task etc. kann man nicht nur für einen SPS Zyklus den Start senden. Die Zykluszeit vom CMMO ist schon langsam.

 

[CL-391]

@NBerger Ich habe Codeschnipsel, allerdings nur von meiner eigenen Steuerschrittkette die den Antrieb befehligt. Ich hab die nicht relevanten Teile raus gekürzt:

CASE #PcbGripper.nStep OF
    (...)
    100: // Warten auf Änderung der Greiferbreite
        IF #strPcbGreifer.OUT."Regler freigegeben"
            AND #strPcbGreifer.OUT.Bereit
            AND NOT #strPcbGreifer.OUT.Warnung
            AND NOT #strPcbGreifer.OUT.Störung
            AND #strPcbGreifer.OUT."Lastspannung OK"
            AND #strPcbGreifer.OUT."Achse referenziert"
            AND NOT #strPcbGreifer.OUT."Start-Rückmeldung" // --> LÖSUNG
        THEN
            IF #PcbGripper.bPositionChanged AND NOT #PcbGripper.bForceControlled THEN
                #strPcbGreifer.IN.Sollposition := #PcbGripper.fGripperWidthOld;
                #strPcbGreifer.IN.Betriebsart := 1;
                #strPcbGreifer.IN."Start Fahrauftrag" := TRUE; // ANFORDERUNG FÜR VERFAHRAUFTRAG, WURDE VOR ÄNDERUNG IM ZWEIFEL SOFORT WIEDER GESETZT
                #PcbGripper.nStep := 110;
                
            (...)
            END_IF;
            
        (...)
        END_IF;
        
    110: // Warten auf Startsignal verarbeitet
        #"Timeout Greifer ansteuern" := TRUE;
        
        IF NOT #strPcbGreifer.OUT."Bewegung beendet" THEN
            #PcbGripper.nStep := 111;
        ELSIF #"Timeout Greifer".Q THEN
            #PcbGripper.nStep := 0;
        END_IF;
        
    111: // Warten auf PCB-Greifer in Position
        #PcbGripper.fCurrPosMin := #strPcbGreifer.IN.Sollposition - 0.5;
        #PcbGripper.fCurrPosMax := #strPcbGreifer.IN.Sollposition + 0.5;
        
        IF #strPcbGreifer.OUT."Bewegung beendet"
            AND (#PcbGripper.fCurrPosMin <= #strPcbGreifer.OUT.Istposition AND #strPcbGreifer.OUT.Istposition <= #PcbGripper.fCurrPosMax)
        THEN
            #strPcbGreifer.IN."Start Fahrauftrag" := FALSE; // NACH BEENDEN EINES FAHRAUFTRAGS WIRD DIE ANFORDERUNG QUITTIERT
            #PcbGripper.bPositionChanged := FALSE;
            #PcbGripper.nStep := 100;
        END_IF;
        (...)
        
    ELSE  // Error Correction
        #PcbGripper.nStep := 0;
END_CASE;

Es handelt sich hier um einen Greifer, dessen Sollwert von einer Robotersteuerung vorgegeben wird. Ein Verfahrauftrag wird ausgelöst sobald sich der gegebene Sollwert gegenüber dem zuletzt Angeforderten verändert.
Im Worst Case (Tippbetrieb) wird der Sollwert quasi fließend verändert, was zu einem dauerhaften Anfordern neuer Fahraufträge führt. Der Tippbetrieb konnte aufgrund der gegebenen Schnittstelle leider nur so realisiert werden auch wenn es mir (und vermutlich vielen anderen) nicht gefällt wie es gelöst ist.

Ich habe die drei an der Störung beteiligten Zeilen noch einmal separat im Code kommentiert.

Gruß Christian