TIA Prozessabbild aktualisieren mit UPDAT_PO

Balu_der_Bär

Level-2
Beiträge
114
Reaktionspunkte
44
Zuviel Werbung?
-> Hier kostenlos registrieren
TIA V15.1

Hallo zusammen,
ich habe zur Zeit ein Projekt mit vielen Digital angeschlossenen Teilnehmern gleichen Types. Der Einfachheit halber sagen wir mal das diese 3 Eingänge und 3 Ausgänge haben.
Um mir arbeit im Programm zu ersparen möchte ich auf diese Teilnehmer in einer Forschleife zugreifen.
Ich hab also einen DB mit Array of Typ UDT wobei dieses UDT die 3 Ein und Ausgänge enthält.

Jetzt ist die Frage wie schaffe ich die EAs in dieses Array.
Theoretisch müsste ich am Anfang von meinem OB1 alle Eingänge in den DB schreiben und am Ende von OB1 alle Ausgänge aus dem DB Lesen und ins PZA schreiben.

Da das UDT in Wirklichkeit viel komplexer ist, will ich das gerne nur an einer zentralen stelle mit Hilfe eines Bausteines pro Teilnehmer realisieren.

Da gibt es dann jedoch einen Nachteil bei der Zykluszeit.

Schreibe ich nach dem Aufruf dieses Bausteins einen Ausgang in mein UDT Array wird dieser erst im nächsten SPS Zyklus ans PZA weiter geleitet. Somit ist jeder Ausgang um einen SPS Zyklus verzögert.

Siemens bietet allerdings auch den Baustein UPDAT_PO bzw SYNC_PO an. Damit kann ich, wenn ich das richtig verstehe, aus dem Programm heraus das Prozessabbild aktualisieren.

Meine Fragen jetzt:
- Habt ihr irgendwelche Erfahrungen zu dem Baustein ?
- wo liegt der genaue unterschied zwischen UPDAT_PO und SYNC_PO.
- Ist dieser Baustein dafür ausgelegt das gesamte PZA zu aktualisieren oder ist es eher für Teilbereiche (wie es in der Hilfe genannt wird) zu gebrauchen.
- Wie sehr leidet die Zykluszeit bei einer Extra Aktualisierung ?

grüße Balu
 
Zuletzt bearbeitet:
Moin,
...Ich hab also einen DB mit Array of Typ UDT wobei dieses UDT die 3 Ein und Ausgänge enthält.
Jetzt ist die Frage wie schaffe ich die EAs in dieses Array.
Theoretisch müsste ich am Anfang von meinem OB1 alle Eingänge in den DB schreiben und am Ende von OB1 alle Ausgänge aus dem DB Lesen und ins PZA schreiben.

Da das UDT in Wirklichkeit viel komplexer ist, will ich das gerne nur an einer zentralen stelle mit Hilfe eines Bausteines pro Teilnehmer realisieren...
Warum legst du diese UDT nicht auch auf den E/A Bereich bei den PLC-Variablen:
EAMapping.JPG
Dann kannst du diese am Zyklusanfang über eine einfache Zuweisung ":=" in deinen DB in jedes einzelne Array-Element kopieren.

1. Habt ihr irgendwelche Erfahrungen zu dem Baustein ?
2. wo liegt der genaue unterschied zwischen UPDAT_PO und SYNC_PO.
3. Ist dieser Baustein dafür ausgelegt das gesamte PZA zu aktualisieren oder ist es eher für Teilbereiche (wie es in der Hilfe genannt wird) zu gebrauchen.
4. Wie sehr leidet die Zykluszeit bei einer Extra Aktualisierung ?
zu 1. UPDAT_PO - funktioniert tadellos
zu 2. SYNC_PO - arbeitet taktsynchron
zu 3. laut Hilfe auch für Teilprozessabbild = 0 = OB1 Prozessabbild
zu 4. kann ich leider nicht beantworten - kommt sicher auf die Größe der zu aktualisierenden Daten an

Grundsätzlich sind die Bausteine meiner Meinung nach für extra Zyklus-OBs, also wenn du neben den OB1 noch einen schnellen Zyklus bspw. für einen Regler nutzt. Dann müssen die EAs des Reglers ja auch schneller gelesen und geschrieben werden, als durch den normalen OB1-Zyklus.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

Warum legst du diese UDT nicht auch auf den E/A Bereich bei den PLC-Variablen:
Anhang anzeigen 46604
Dann kannst du diese am Zyklusanfang über eine einfache Zuweisung ":=" in deinen DB in jedes einzelne Array-Element kopieren.

Weil das nur bedingt funktioniert.:
- es muss immer beim vollen Byte beginnen. Problematisch also wenn man mehrere udts hintereinander hat die nicht immer das ganze byte ausfüllen
- bei Ausgängen muss man deswegen extra aufpassen weil ein udt von x.0-x.4 beim beschreiben automatisch x.5-x.7 mit 0 überschreibt
- bringt mir in diesem fall nicht viel weil ich dann ja wieder Eingänge von Ausgängen trennen muss weil es nicht gemischt sein kann.

Aber ich werde es mal ausprobieren . sonst quäl ich mal die siemens hotline inwiefern so ein erneutes aktualisieren die zyklusszeit verlängert.

grüße Balu
 
Moin Balu_der_Bär,

- es muss immer beim vollen Byte beginnen.

Ich würde sogar das volle Word bevorzugen.

Problematisch also wenn man mehrere udts hintereinander hat die nicht immer das ganze byte ausfüllen

Warum die UDT nicht immer so auffüllen, dass ein ganzes Byte (Word) belegt wird?

- bei Ausgängen muss man deswegen extra aufpassen weil ein udt von x.0-x.4 beim beschreiben automatisch x.5-x.7 mit 0 überschreibt

das würde dann nicht mehr als Problem auftreten.

- bringt mir in diesem fall nicht viel weil ich dann ja wieder Eingänge von Ausgängen trennen muss weil es nicht gemischt sein kann.

Aber (wenn wir mal bei einem Byte und nicht bei einem Word bleiben), müsste die Deklaration, das Mapping (was auch immer) der EIN-/Ausgänge trotzdem noch im Projekt gemacht werden. Also ergibt das doch gar kein Mehraufwand oder habe ich da etwas falsch verstanden?


Sorry, ja, da hatte ich etwas falsch verstanden :rolleyes:

VG

MFreiberger
 
Zuletzt bearbeitet:
Weil das nur bedingt funktioniert.:
- es muss immer beim vollen Byte beginnen. Problematisch also wenn man mehrere udts hintereinander hat die nicht immer das ganze byte ausfüllen
- bei Ausgängen muss man deswegen extra aufpassen weil ein udt von x.0-x.4 beim beschreiben automatisch x.5-x.7 mit 0 überschreibt
- bringt mir in diesem fall nicht viel weil ich dann ja wieder Eingänge von Ausgängen trennen muss weil es nicht gemischt sein kann.
Ein- und Ausgänge sind bei mir deshalb je eine eigene UDT - die wiederum bilden eine "Ober"-UDT. Also UDT_Prozessdaten besteht aus UDT_Eingänge und UDT_Ausgänge.
Mit den Adressen hast du natürlich recht, aber die lege ich halt im Planungsprozess dorthin, wo ich sie brauche - und sehe entsprechende Lücken vor. Das neue Structs/UDTs immer auf einem neuen Wort beginnen, war ja auch schon im Classic so. Auch dort musste man in diesen Fällen bspw. mit dem SFC15 und 15 aufpassen, was man ließt und schreibt, wenn die Prozessdaten zu klein sind.

In Summe halte ich das trotzdem für den richtigeren Weg ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn man die Ein und Ausgänge selbst planen würde dann wäre es sicher möglich ja. Wenn ich jedoch meinem Konstrukteur erzähle das er viele E/As freilassen muss und die nicht verwendet werden dürfen zeigt der mir nen Vogel :D

Aber selbst wenn löst es ja nicht das eigentliche Problem.

Siemens spricht ja immer von Parametrieren statt Programmieren.
Als beispiel einen Greifer:
2 Ausgänge ( auf/zu) 2 Eingänge(offen/geschlossen)

Für diese gibt es jedoch unzählige Variationen:
- teil wird gegriffen wenn offen bzw wenn geschlossen
- nur ein oder gar kein Sensor möglich weil der Hub weg zu klein ist.
- Übergriff Überwachung gewünscht.

Da diese Sachen meist erst bei der IBN auffallen/gefordert werden und dann meist "qick and dirty" reinprogrammiert werden will ich das von vorn herein über Parameter einstellbar machen.

Dieser Baustein liest aus meinem Objekt DB also den Soll zustand dieses Greifers und schreibt zurück den Ist zustand.
welcher Ausgang aber nun angesteuert wird und auf welchen Eingang gehört und wie dieser benutzt wird, wird über die Parameter im DB bestimmt.

Wo soll ich diesen Baustein nun aufrufen ? Wenn ich es am Anfang des Ob1 mache sind meine Ausgänge um 1 Zyklus verzögert.
Mache ich es am ende des Obs sind meine Eingänge um 1 Zyklus verzögert.

Daher will ich das PZA manuell erneuern bevor ich all diese Bausteine aufrufe.
 
Warum teilst du nicht?
Eingangstatus aktualisieren am Zyklus Anfang (Anfang OB1)

Dann allen Quatsch machen den man grade möchte...

Dann Ausgangsstatus aktualisieren am Zyklus Ende (Ende OB1)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn man die Ein und Ausgänge selbst planen würde dann wäre es sicher möglich ja. Wenn ich jedoch meinem Konstrukteur erzähle das er viele E/As freilassen muss und die nicht verwendet werden dürfen zeigt der mir nen Vogel :D
Das Argument verstehe ich nicht. Dein Konstrukteur gibt einfach nur irgendwelche Adresse in seinem E-Plan ein und ist dann mit dem Thema durch. Und du, der damit ggf. über Monate hinweg arbeiten muss - darf da keine Vorgaben machen? :confused:
In solchen Fällen ist dann aber nicht TIA oder Siemens das Problem ;)
Dieser Baustein liest aus meinem Objekt DB also den Soll zustand dieses Greifers und schreibt zurück den Ist zustand.
welcher Ausgang aber nun angesteuert wird und auf welchen Eingang gehört und wie dieser benutzt wird, wird über die Parameter im DB bestimmt.
So ganz habe ich das ehrlich gesagt nicht verstanden ... aber kannst du das ganze nicht trennen und mit deinem Parameter-DB am Anfang des Zyklus zunächst entscheiden auf welchen Sensor gehört wird - dann kommt der ganze Ablauf (wahrscheinlich auch parametrierbar) und dann kommt zum Zyklus-Ende wieder dein Parameter-DB und entscheidet welche Ausgänge geschrieben werden?
 
Das wäre Plan B wenn es besser nicht geht.
Solange ich Hoffnung habe das es geht geb ich noch nicht auf :wink:
Halte ich für Unsinn !!!

Die SPS arbeitet nach Prinzip EVA - Am besten ist,- man lebt das auch.

Gegen das Systemarbeiten macht nur Probleme und damit Ärger.
 
Ich will halt verhinden für jedes Objekt 2 Bausteine in der Bib Ablegen zu müssen.
aber sicher hast du recht das man sich an gewisse grundregeln halten sollte.
ich warte mal ab was der Siemens Support sagt.

Grüße

Balu
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wo soll ich diesen Baustein nun aufrufen ? Wenn ich es am Anfang des Ob1 mache sind meine Ausgänge um 1 Zyklus verzögert.
Mache ich es am ende des Obs sind meine Eingänge um 1 Zyklus verzögert.
Wenn ich Dich richtig verstanden habe, macht Dir nicht das Lesen der PEW KopfGrimmen, sondern nur das Schreiben der PAW.
Damit ist Deine Frage doch beantwortet: Du rufst den Baustein am Ende des OB1-Zyklus auf und liest nur die PEW.
 
Zurück
Oben