Problem mit Verständniss für Programmstruktur

Peter_AUT

Level-1
Beiträge
96
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

Eine 314C-2DP ist über Ethernet an WinCC (nicht flex!) angeschlossen.
Die Daten werden über einen Globaldatenbaustein ausgetauscht.

Jetzt kommt meine Frage:
Der Programmierer hat in jeden FB wo er Daten aus der Visualisierung
braucht, diese über eine Pointer/Adressregisterkonstruktion vom
Globaldatenbaustein in den lokalen Speicher des FB kopiert.
Am Ende des Bausteins kopiert er die Daten wieder zurück.

Welchen Vorteil kann diese Vorgehensweise haben?
Ich frage mich, ob ich diese Struktur fortführen soll, sehe aber
nicht wirklich einen Sinn dahinter.

Danke für alle Antworten und schöne Grüße
 
Hallo Peter,

der Vorteil, den ich in dieser Vorgehensweise sehe ist, dass Zugriffe auf den lokalen Speicher schneller sind als DB-Zugriffe.
Wird also sehr oft auf den Global-DB zugegriffen, würde ich das so beibehalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sollte das dann aber nicht sinnvollerweise auf einmal (z.B. mit BLKMOV)
passieren? Wenn ich für jedes Wort den Pointer errechne, zugreife und
kopiere (so wie jetzt) habe ich ja nicht wirklich einen Geschwindigkeitsvorteil.

Viele Zugriffe ist relativ - so ca. 5-10 Wörter - vielleicht werden es mal 50 insgesamt.
Da die Anwendung nicht zeitkritisch ist, steht die Reduktion der Übersichtlichkeit meiner
Meinung nach nicht in Relation mit dem Geschwindigkeitsgewinn von ein paar µs
 
Zuletzt bearbeitet:
Ja, ein BLKMOV wäre hier auf jeden Fall sinnvoll.
Und wenn es nur um ein paar Zugriffe geht, spielt die Geschwindigkeit keine SO große Rolle - da kann man aber keine generelle Aussage treffen, sondern das kann man nur dann beurteilen, wenn man die Anlage (CPU, Auslastung, ...) kennt.
 
Hallo

Ich nehme an, die FBs, in denen umkopiert wird, sind instanzierbar d.h. werden für mehrere Einheiten (Geräte,Motoren,...) verwendet. Den globalen Visu-DB gibt es dagegen nur einmal.

Jede FB-Instanz kopiert nun Daten von einer anderen Stelle im globalen Visu-DB hin- und her.

Alternativen:
- Würde der FB nun fest auf die gleichen Daten zugreifen, wäre er nicht mehr instanzierbar. Jeder Motor/jedes Gerät braucht ja einen eigenen Visu-Datenbereich. Das geht also nicht.

- Würde man nicht umkopieren, sondern bei jedem Zugriff mit Pointern arbeiten, wäre die ganze Sache ziemlich undurchsichtig. Die Symbole für die Variablen fehlen und man weiß irgendwann gar nicht mehr, auf was man da gerade schreibt -> no go

Ich denke also es hat nichts mit der Zykluszeit zu tun. Der Programmierer kopiert am Anfang und Ende um. Das ist noch überschaubar. Im Baustein kann er dann mit den lokalen Symbolen arbeiten. Zum Schluss wird es zurück kopiert.
Hab ich schon oft gesehen. Meine Kollegen machen das auch ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sehe ich genauso. Der Geschwindigkeitsvorteil bei einem Global-DB für die Visu liegt dabei auf der WinCC-Seite beim Bildaufbau. Wir machen es oft so, das gekapselte Funktionen wie z.B. ein Motor-FC mit einer INOUT-Variable (UDT, Struct) versehen ist, in denen die Daten abgelegt werden. Der Global-DB enthält dann die Motor-UDT's, die man dann wunderbar im WinCC als Strukturvariable anlegen kann.

Gruß Approx
 
Noch ein Vorteil ist, dass man mit dieser Art nur einen FC statt FB braucht und die statischen Variablen liegen halt in dem GlobalDB (über die IN/OUT).
Über die Sache mit den UDT ist das auch noch akzeptabel übersichtlich.

SO richtig elegant finde ich diese Lösung auch nicht, ist aber bei Siemens einfach ziemlich praktisch.

Hab ich selbst bei Vorlagen von Siemens schon so gesehen.

- Du kannst dabei eben auch im laufenden Betrieb schnell mal eben nur von einer zur anderen Instanzen (ist ja nur GlobalDB) wechseln und auch auf einen ganz anderen DB legen falls du den aktuellen gerade nicht anfassen möchtest.

- Die Alternative mit dem FB und InstanzDB ist halt immer etwas schwierig, musst unter Umständen in dem aufrufenden Baustein die Schnittstelle ändern, dann auch den DB noch neu übertragen und in dem darunter liegenden Baustein auch noch den Aufruf aktualisieren.
Musst du gar etwas an den Daten der statischen Variablen ändern verschieben sich womöglich auch noch deine Datenpunkte für dein HMI.
 
Zurück
Oben