TIA LCom Bibliothek

I

Ingmar64

Level-2
Beiträge
326
Reaktionspunkte
53
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe mit der LCom-Bibliothek von Siemens eine Kopplung zwischen einer 315PNDP und einer 1511PN mit beidseitigem Senden aufgebaut. Es funktioniert auch prinzipiell. Das Senden erfolgt zum Testen erstmal auf beiden Seiten zyklisch alle 100ms. Ich habe jetzt den Effekt, daß die 1500er nach einiger Zeit mit einem Zykluszeitfehler in Stop geht, obwohl daß Programm außer den Kommunikationsaufrufen nichts enthält und auch dort keinerlei Schleifen, die so etwas normalerweise verursachen.
Hat da jemand schon mal Erfahrung damit und könnte Tipps geben?
 
Da war doch was bei S7-1500... Beobachtest Du das Programm mit dem PG?
Eventuell hilft es, der (HMI-)Kommunikation mehr Zeit (%) einzustellen.

Harald
 
Hallo ingmar,

diese 50% können das Prob sein wo liegt deine Zykluszeit im Schitt? Ich würde bei der Begrenzung mal ca min das doppelte wenn nicht das3 fache einstellen.

Gruß Tia
 
Also die Zykluszeit schwankt zwischen 9 und 13 ms, eingestellt war max. 150ms. Ich habe jetzt 500ms eingestellt und den OB80-Aufruf unterdrückt, mal sehen, ob es morgen früh noch läuft und was so alles im Diagnosepuffer steht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht müsste man die zulässige Kommunikationslast eher verringern? Vielleicht hat man bei der S7-1500-CPU-Firmware aber auch gar keine reale Chance?
Ich erinnere mich, daß es Beiträge wg. Aussetzern der Profibus- und Profinet-Komm. und Zykluszeit-Überschreitungen durch Online-Funktionen von TIA gab, z.B.: Online Probleme TIA V13

Bist Du sicher, daß da in den LCom-Bausteinen keine Schleifen drin sind? Kann man deren Quelltext lesen?

Harald
 
Ich verwende TIA15, vermute aber mal, daß da nicht die Ursache liegt.

Ja, man kann den Quelltext lesen, ist in SCL.

Es gibt Goto-Befehle, aber nur ans Ende. Sollte ok sein.

Es FOR-Schleifen mit einem USINT-Wert, erklärt selbst bei einem Fehler nicht den Anstieg der Zykluszeit von 10ms auf >1000ms.

Es gibt eine Repeat-Schleife zum Zusammenbasteln der Empfangsdaten. Da der Fehler aber nur auftritt, wenn das Senden zyklisch nach Abschluß des letzten Sendens immer wieder neu angestoßen wird, vermute ich erstmal, daß da nicht die Ursache liegt. Baue ich eine Verzögerung >50ms zwischen Ende Senden und Neustart Senden ein, wird es deutlich stabiler, es lief immerhin gestern von 18:00 bis 22:00, dann ging die CPU nach der zweiten Zykluszeitüberschreitung in Stop.

Der von Dir verlinkte Beitrag ist interessant, manches kommt mir bekannt vor. Ich werde versuchen, meinem Chef eine 1515 zu entlocken, vielleicht ist die stabiler.

OT: Bei der Vipa-Serie 200 kann man die CPU über den MPI-Bus abschießen, wenn mann zu viele Variable liest (z.B. HMI+PG), bzw. sie läuft überhaupt nicht an, wenn während des Hochlaufs ein umfangreicher Zugriff stattfindet. Bei den 300er von Siemens hatte ich das noch nicht, weder über MPI noch über PN.
 
Moin,

also mit verlaub, wenn nur die Kommunikationtreiber in der Steuerung laufen und sonst nix - dann glaube ich, das der Fehler auch nur dort zu finden ist ;)
Insbesondere ein falsches Goto oder Repeat deutet doch arg darauf hin.
Poste doch mal den Code der Schleifen, dann kann man da mal drauf schauen.
 
Krass, dass das von Siemens kommt. Der Code entspricht jetzt nicht so ganz deren Style Guide.
Hast du auch noch einen Screenshot vom Diagnosepuffer mit dem Zykluszeitfehler?
Und vielleicht einen Screen von deiner Beschaltung des LCom_Comm-Bausteins?
 
LCom Einbindung und Zyklusfehler

Anhang anzeigen FB_Hang_Receive.txtZyklusfehler.jpg

Bitte schön. Es sind nur Testroutinen. In der Anlage selbst wird dann später mal das Senden durch den Prozess angestoßen, bloß kann das auch mal kurz hintereinander sein. Aber mit alle 100ms Abstand könnte die Anlage gut leben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kannst du im Diagnosepuffer auch noch mal den Fehler "Zykluszeit überschritten" markieren und einen Screenshot machen? (Damit man dort die "Hilfe zum Ereignis sehen kann")
 
Zyklusfehler1.jpgZyklusfehler2.jpgBausteine.PNG
Da es in der Hilfe heißt "verschachtelter Aufruf von Alarm-OB's" habe ich die Programmstruktuir mal mit angehängt. Es gibt keine weiteren OB's als OB1 und OB100.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Er springt dann in die Gerätesicht. Das führt mich zumindest auch nicht weiter.
Ich habe mal jetzt eine Mindestzykluszeit von 30ms eingestellt, das Programm selbst enthält nach wie vor nichts außer der Kommunikation. Jetzt geht die CPU reproduzierbar nach ca. 10s in Stop.
 
Dann würde ich dir als nächstes empfehlen, mal ein Trace von den Laufvariablen der Schleifen anzufertigen und zu schauen ob die irgendwie weglaufen.
 
Danke für den Tipp.
Ich bekomme morgen eine niegelnagelneue 1515 zum Testen. Dann werden wir weitersehen. Im Moment tippe ich eher auf einen Firmwarefehler, irgendein Problem im TCP-Stack, als auf einen Fehler im Anwendungsprogramm. Denn ein OB1 mit einer Laufzeit von 1ms, der alle 30ms aufgerufen wird (Mindestzykluszeit) sollte sich ja eigentlich problemlos unterbrechen lassen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also bei uns läuft die LCOM Kommunikation mit 20ms zwischen 2 S7-507S(F) Firmware 2.1 in TIA V15 erstellt.
Mit einer kleinen Portion Anwenderprogramm in dem Programm_Alarm auch Last erzeugt.


Gruß

J.
 
Meine 1511 hat Firmware 1.8.4, das ist zwar die neueste für diesen Typ aber eben auch schon "uralt". Aber danke für die tröstenden Worte. Ich hoffe auf morgen.
 

Similar threads

L
Step 7 MQTT - IoT und Machine2Machine Kommunikation für Siemens S7
Antworten
7
Aufrufe
26K
INSEVIS-Service
INSEVIS-Service
Zurück
Oben