In/OUT Datenstruktur über mehrere FB durchreichen

hubert · 23 Mai 2010

Hallo Leute,
hab da mal eine kleine frage an euch. Habe mir einen FB für einen Antrieb erstellt. In diesem Antriebs-FB ruf ich einen weiteren FB auf der für die HMI-Anbindung zuständig ist. Der hat einen IN/OUT Struktur von einem UDT. In einem übergeorten FB rufen ich diesen Antriebs-FB mehrfach aus. Was ich nun für ein Problem habe ist. Diese Struktur (UDT) durch drei Bausteine durch zu rangieren. Schon bei der ersten hat er eine Problem, das der die IN/OUT-Variable des übergeordneten FB's nicht im darunterliegenden als IN/OUT aufnimmt. Sie ist immer rot. Was ist die ursache dafür bzw. kann mir einer das erklären?

Thomas_v2.1 · 23 Mai 2010

Hallo hubert,

das Thema wurde schonmal diskutiert, vielleicht hilft es dir ja erstmal weiter:

http://www.sps-forum.de/showthread.php?t=33957

Jochen Kühner · 23 Mai 2010

hubert schrieb:
Hallo Leute,
hab da mal eine kleine frage an euch. Habe mir einen FB für einen Antrieb erstellt. In diesem Antriebs-FB ruf ich einen weiteren FB auf der für die HMI-Anbindung zuständig ist. Der hat einen IN/OUT Struktur von einem UDT. In einem übergeorten FB rufen ich diesen Antriebs-FB mehrfach aus. Was ich nun für ein Problem habe ist. Diese Struktur (UDT) durch drei Bausteine durch zu rangieren. Schon bei der ersten hat er eine Problem, das der die IN/OUT-Variable des übergeordneten FB's nicht im darunterliegenden als IN/OUT aufnimmt. Sie ist immer rot. Was ist die ursache dafür bzw. kann mir einer das erklären?

Wir hatten das an unseren Antrieben auch mal so (also das mt den UDTs)! Da dies aber viel zu viel Zyklus zeit verbraucht haben wir nun im Antriebs FC einen Any Pointer, und lesen im FC intern Indirekt die Daten...

hardwarekiller · 24 Mai 2010

Jochen Kühner schrieb:
Wir hatten das an unseren Antrieben auch mal so (also das mt den UDTs)! Da dies aber viel zu viel Zyklus zeit verbraucht haben wir nun im Antriebs FC einen Any Pointer, und lesen im FC intern Indirekt die Daten...

Die indirekte Ansprache der HMI-Struktur ist auch mein aktueller Lösungsansatz in meinen Standard-FBs.
Bin aber aktuell am Überlegen ob es nicht übersichtlicher ist sich die Daten per BlockMove als Tempvariablen zu holen, damit zu arbeiten und am Schluss wieder per BlockMove zurück in den HMI DB zu schreiben.

hubert · 24 Mai 2010

Hallo Leute,
danke schon mal für eueren Radschlag. Das mit der Indirekten-Adressierung hab ich bis jetzt auch gemacht. Nur ist es für manche Kollegen etwas umständlich. Dachte es ginge bei Siemens auf jedenfall mit den UDT's und dem durchrangieren von IN/OUT Datentypen. Aber das scheint nicht der Fall zu sein. Dann muss ich es halt doch wieder indirekte manchen.

@Jochen Kühner. Wie macht in das in der Firma um Zykluszeit zu sparen. Ein Kollege von mir schießt mit der indirekten Adresserierung recht hoch. Hat jetzt schon eine schnellere CPU gebraucht um die Prozesszeiten einhalten zu können. Wäre für eine kurze Info von dir dankbar.

Jochen Kühner · 24 Mai 2010

hubert schrieb:
@Jochen Kühner. Wie macht in das in der Firma um Zykluszeit zu sparen. Ein Kollege von mir schießt mit der indirekten Adresserierung recht hoch. Hat jetzt schon eine schnellere CPU gebraucht um die Prozesszeiten einhalten zu können. Wäre für eine kurze Info von dir dankbar.

Beispiel unser ANtriebs Bausteine.

Früher hatten wir einen In/Out mit unserem UDT der Antriebsdaten, doch dies hat zuviel Zyklus Zeit gekostet. Nun haben wir aus diesm UDT In/Out einen Any In/Out gemacht. D.h. der Aufrug des FCs bleibt der gleiche, wir hängen immer noch die Antriebsdaten an den FC, aber im FC greifen wir direkt über das AR und den entsprechenden versatz auf unsere Werte zu. Hat halt den nachteil das man im FC nicht mit Symbolischen Adressen arbeiten kann.
Wir schreiben dann halt immer direkt dahinter ein Kommentar welches Bit/Wort gemeint ist!

Bsp:

= [AR1,P#40.0] //UDT_ANTRIEBE.SAMMELSTÖRUNG

Das mit dem Umkopieren in Lokaldaten hatte Ich auch überlegt, kostet halt aber auch wieder Zykluszeit!

hubert · 24 Mai 2010

Hallo Jochen,

danke schon mal für den Tipp. Wie du schon gesagt hast die Sache hat einen kleinen Nachteil (Symbolik). Aber meistens ist es so da wo eine Vorteil ist ist auch mal ein kleiner Nachteil. Aber meistens ändert man in solchen Standardbausteinen eh nicht viel mehr wenn sie mal ausführlich getestet sind.

Larry Laffer · 24 Mai 2010

Hallo,
auf eine sinnvolle Zuordnung der UDT-Inhalte zu verzichten zugunsten einer Zeitersparnis halte ich zumindestens für extrem fragwürdig. Ob es nicht eventuell Nonsens ist stellt sich spätestens dann heraus, wenn man da nach einiger Zeit mal wieder dran muß ...

Aber zu dem Thema :
Willst du den UDT per value durchreichen, oder eigentlich "nur" als Pointer ? Im 2. Fall bräuchtest du dir von dem UDT nur ein Pointer-Abbild (im TEMP-Bereich) spiegeln und dieses kannst du dann weiterreichen.

Gruß
LL

vierlagig · 25 Mai 2010

erstelle deine (teil)anlagen datenstruktur in einem UDT.
erstelle einen übergeordneten FB, dessen STAT aus dieser UDT besteht.
füge die UDT in jeden aufgerufenen FB ein.
rufe die FBs über UC auf.

du hast so in allen aufgerufenen FBs immer alle daten deiner (teil)anlage zur verfügung.

SPSKILLER · 25 Mai 2010

Hi,

HMI Daten gehören IMHO in den FB!
Das ist Siemens Philosophie.

Es ist doch Quatsch die Daten doppelt zu halten, nur um einen Schnittstellen-DB für die HMI zu haben.
Bei Flexible kann man das ja noch durchgehen lassen, aber bei "richtigem" WinCC bzw. PCS7 ist die tolle Bibliothek dann nicht mehr zu gebrauchen.

Micha

In/OUT Datenstruktur über mehrere FB durchreichen

hubert

Level-2

Thomas_v2.1

Level-1

Jochen Kühner

Level-3

hardwarekiller

Level-1

hubert

Level-2

Jochen Kühner

Level-3

hubert

Level-2

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

vierlagig

Level-1

SPSKILLER

Level-2

Similar threads

Wir schützen deine Privatsphäre