TIA Ansteuerung der PUT-GET-Kommunikation mit FlipFlop oder Statusmaschine

[Burkhard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebe Siemens-Experten.

Ich habe die folgende PUT-GET-Kommunikation zwischen einer S7-1200 und einer S5 mit dem S5 Lan++ Adapter implementiert, die ich mit einem Flip-Flop steuere.



Wie ihr seht, habe ich eine Zykluszeit von 8ms (HIGH) und 8ms (LOW) also 16ms bis zum nächsten Trigger.



Hier ist die PUT-Kommunikation, die mit dem gleichen Trigger wie die GET-Kommunikation ausgeführt wird.



Dies ist die GET-Kommunikation die mit dem gleichen Trigger wie die PUT-Kommunikation ausgeführt wird.

Als ich die Länge des zu lesenden Bereiches von 1 BYTE auf 20 BYTE erhöht habe, bemerkte ich,
dass am STATUS-Ausgang des GET-Bausteins zusätzlich zum Wert Hex-19 (25) auch der Wert Hex-0B (11) erschien.



Dies führte mich zum Hilfesystem, das mir mitteilte, das der Trigger (Auftrag) unwirksam sei, da der vorhergehende Auftrag noch nicht abgeschlossen ist.

Ich habe nun mehrere Möglichkeiten. Ich ignoriere die Warnung, da der Baustein robust genug ist, da er keinen ERROR meldet. Denn beim nächsten Trigger, nach erneut 16ms wird der Auftrag dann ja abgearbeitet.

Ich habe das in meiner Beobachtungstabelle geprüft:



Oder ich implementiere eine Statusmaschine, damit ich immer warte, bis der GET Baustein sein NDR oder der PUT Baustein sein DONE sendet, und dann gehe ich in den nächsten Schritt.

Es handelt sich um die Übertragung von Signalen für Ventile in einer Wickel-Anlage für Elektromotoren in einem Automobilzulieferer. Welchen Weg würden mir die Experten hier im Forum befehlen?

 

[DeltaMikeAir]

Dies führte mich zum Hilfesystem, das mir mitteilte, das der Trigger (Auftrag) unwirksam sei, da der vorhergehende Auftrag noch nicht abgeschlossen ist.

Klingt ja auch absolut plausibel. 16ms macht für mich eigentlich überhaupt keinen Sinn. Die Geschwindigkeit der Übertragung ist nicht über den S5-Lan++ Adapter limitiert sondern über die S5 Schnittstelle ( 9600 Baud ).

Ich würde mit DONE + ERROR + einem selbstgenerierten Timeout arbeiten. Schau mal hier:
https://www.sps-forum.de/threads/put-funktioniert-trotz-grüner-verbindung-nicht.103694/#post-784987

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also statemachine (Schrittkette) macht bei sowas eigentlich schon Sinn.
Vorallem kannst du dann auch ein vernünftiges Fehlerhandling einbauen.
Und auch Dinge wie das Loschen des Input-Bereiches des Get einbauen.
16ms ist bei ner S5 extremst sportlich.

 

[DeltaMikeAir]

Einen Tipp noch aus eigener Erfahrung. Wenn die S5-Lan++ Adapter mal länger laufen ( 12 Monate oder mehr ), dann kann es sein dass sie sich "aufhängen". Dass äußert sich dann so, dass an den PUT/GET Bausteinen der Status HEX19/DEZ25 hängen bleiben. Dies auch mit der aktuellsten Firmwareversion. Einzigste Abhilfe, damit er dann wieder weiter kommuniziert ist, ihn kurz spannungsfrei zu machen und dann wieder zu starten. Dann läuft er wieder. Schon öfters erlebt mittlerweile. Wie gesagt, passiert meist nach > 12 Monaten Dauer-An.

 

[rar-101]

16ms ist bei ner S5 extremst sportlich.

Ich habe noch keine S5 mit 16ms Zykluszeit gesehen die Produktiv eingesetzt ist/war.

Einen Tipp noch aus eigener Erfahrung. Wenn die S5-Lan++ Adapter mal länger laufen ( 12 Monate oder mehr ), dann kann es sein dass sie sich "aufhängen". Dass äußert sich dann so, dass an den PUT/GET Bausteinen der Status HEX19/DEZ25 hängen bleiben. Dies auch mit der aktuellsten Firmwareversion. Einzigste Abhilfe, damit er dann wieder weiter kommuniziert ist, ihn kurz spannungsfrei zu machen und dann wieder zu starten. Dann läuft er wieder. Schon öfters erlebt mittlerweile. Wie gesagt, passiert meist nach > 12 Monaten Dauer-An.

Das Thema hatten wir letztens, es sollten alle S5en mit den Adaptern versehen werden um u.a. im Homeoffice darauf zuzugreifen. Meine Meinung dazu ist das ich am Programm nur mit (m)einem PG mit echter TTY Schnittstelle vor Ort arbeite...
Für Datenverbindung ist das ok, aber denn mit "Jahresreset"...

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meine Meinung dazu ist das ich am Programm nur mit (m)einem PG mit echter TTY Schnittstelle vor Ort arbeite...

Wobei das gut funktioniert. Mit Step5 über ein Netzwerk auf die S5 ( per ViritualCOM ).

 

[Blockmove]

Ich habe noch keine S5 mit 16ms Zykluszeit gesehen die Produktiv eingesetzt ist/war.

Auch bei den S5en gab es schnelle Kisten. War eine reine Geldfrage und eine Frage der richtigen Programmierung.
Eine 155U mit 4 CPUs hat schon was gerissen. Da hat man auch bei einem Retrofit auf S7 genau hinschauen müssen bei der Hardware-Auswahl.
Klar gibt es auch Kisten mit 200ms.

 

[DeltaMikeAir]

Wie gesagt, mit der Schnittstelle mit 9600 Baud hat man schon einen Flaschenhals. Wenn dann da noch ein Panel auf der Schnittstelle hängt und man einen Multiplexer nutzt....

Es handelt sich um die Übertragung von Signalen für Ventile in einer Wickel-Anlage für Elektromotoren in einem Automobilzulieferer. Welchen Weg würden mir die Experten hier im Forum befehlen?

Wenn es wirklich schnell sein muss, dann gibt es z.b. von Inat schnelle Kommunikationskarten.

Kannst du die Aufgabe mal genauer beschreiben? Evtl. gibt es ja noch einen ganz anderen Weg.

 

[Burkhard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie gesagt, mit der Schnittstelle mit 9600 Baud hat man schon einen Flaschenhals. Wenn dann da noch ein Panel auf der Schnittstelle hängt und man einen Multiplexer nutzt....

Wenn es wirklich schnell sein muss, dann gibt es z.b. von Inat schnelle Kommunikationskarten.

Nein, es gibt keine Vorgabe für die Geschwindigkeit, ich wollte mich nur mal rantasten. Ich habe nun das FlipFlop in eine State-Machine umgewandelt um die echten Übertragungszeiten zu messen.





Die Messung der Arbeitszeiten der PUT und GET Funktionen erfolgen mit jeweils einem TON-Timer, der mit dem REQUEST getriggert wird.




Damit komme ich nun auf folgende Ergebnisse:

Also bin ich bei Werten von 130-170ms.




Ich dachte zwar, ich sei etwas schneller, aber laut Rücksprache mit der Fa. PROCESS INFORMATIK sind diese Zeiten absolut realistisch, da die PG-Schnittstelle der S5 ein limitierender Faktor ist die Kommunikation mit PUT-GET nun mal etwas Zeit benötigt.

 

[Burkhard]

Kannst du die Aufgabe mal genauer beschreiben? Evtl. gibt es ja noch einen ganz anderen Weg.

Es geht um die Ersetzung einer alten EA-Baugruppe mit einem ET-100 Bus, dessen Komponenten nicht mehr erhältlich sind. Die Anbindung soll nun über Profinet-Baugruppen erfolgen. Das ganze soll, wie oben ersichtlich, über den S5 LAN++ Adapter and der PG Schnittstelle der S5 hin zur S7-1200 erfolgen (Die abgebildete S7-300 oben ist nicht korrekt). Dazu muss ich 20 Bytes an Ausgangsdaten von der S5 lesen und etwas weniger Eingangsdaten zur S5 schreiben.

 

[Process-Informatik GmbH]

Die Zugriffszeit maximieren geht mit der S5 nur, wenn man:
- alle Daten in einem Datenbaustein hat und man nur diesen ausliest (so hat man immer nur 1 Zugriff auf alle Daten anstatt mehrere Zugriffe im verteilten Speicher der S5
- die Option "DB-Adressen zyklisch ermitteln" deaktiviert. Dies aber bitte nur wenn keine Änderungen am Programm der S5-SPS durchgeführt werden. Dann holt sich das Modul beim Hochfahren die Adressen der Datenbausteine und nutzt diese dann. Und holt nicht zyklisch immer wieder diese Adressen, was von der Kommunikationszeit weg geht. Ist keine Änderung am Programm bleibt der Speicher konstant und es gibt keine Verschiebungen in den Adressen der Dbs. Somit müssen auch nicht zyklisch die Speicheradressen ermittelt werden.

Dies sind die einzigen Möglichkeiten um den Zugriff zu maximieren. Der Flaschenhals sitzt bei der PG-Schnittstelle der S5-SPS mit 9600 Baud. Und die sind fix, daran kann man nicht rütteln.

Eine reibungslose Kommunikation bekommt man nur so hin wenn man den Status von PUT und GET prüft und neue Aufträge nur startet wenn die bestehenden fertig und abgeschlossen sind. Diese Funktionen über einen festen Timer aufzurufen empfehlen wir nicht, das macht keine Sinn. Es hängt davon ab dass der letzte Zugriff fertig ist. Die S5 lässt keine mehrfache Zugriffe/Kommunikationen über die PG-Schnittstelle zu.

 

[Burkhard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Zugriffszeit maximieren geht mit der S5 nur, wenn man:
- alle Daten in einem Datenbaustein hat und man nur diesen ausliest (so hat man immer nur 1 Zugriff auf alle Daten anstatt mehrere Zugriffe im verteilten Speicher der S5
- die Option "DB-Adressen zyklisch ermitteln" deaktiviert. Dies aber bitte nur wenn keine Änderungen am Programm der S5-SPS durchgeführt werden. Dann holt sich das Modul beim Hochfahren die Adressen der Datenbausteine und nutzt diese dann. Und holt nicht zyklisch immer wieder diese Adressen, was von der Kommunikationszeit weg geht. Ist keine Änderung am Programm bleibt der Speicher konstant und es gibt keine Verschiebungen in den Adressen der Dbs. Somit müssen auch nicht zyklisch die Speicheradressen ermittelt werden.

Dies sind die einzigen Möglichkeiten um den Zugriff zu maximieren. Der Flaschenhals sitzt bei der PG-Schnittstelle der S5-SPS mit 9600 Baud. Und die sind fix, daran kann man nicht rütteln.

Eine reibungslose Kommunikation bekommt man nur so hin wenn man den Status von PUT und GET prüft und neue Aufträge nur startet wenn die bestehenden fertig und abgeschlossen sind. Diese Funktionen über einen festen Timer aufzurufen empfehlen wir nicht, das macht keine Sinn. Es hängt davon ab dass der letzte Zugriff fertig ist. Die S5 lässt keine mehrfache Zugriffe/Kommunikationen über die PG-Schnittstelle zu.

Sehr wahre und weise Worte von PROCESS INFORMATIK. Vielen Dank für die professionelle und freundliche Unterstützung durch diese Firma!