Nutzung von Instanzdatenbausteinen...

Jochen Kühner

Level-3
Beiträge
4.291
Reaktionspunkte
525
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, Ich wollte mal Fragen wie bei euch so die programmier Philosophien aussehen. Nutzt Ihr instanzdatenbausteine nur für im FB notwendige zu speichernde werte, oder werden bei euch auch Parameter in Instanzdatenbausteinen hinterlegt (mit dem problem das Sie nach dem ändern des FB's verloren sind).

Was gibts da für Ideen, Philosophien,...
 
Für allgemeine Paratmeter gibt es die Globaldatenbausteine.
Und jedem FB sein eigener IDB,oder Multiinstanz.
Alles andere ist meiner Meinung nach nicht sauber.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Weil ich meist...

... gleiche Anlagen mit gleichen FB`s verwende ist es für mich auch recht praktisch Parameter und Daten direkt aus dem I-DB zu holen/schreiben. Vor allen da Teile des Programmes 2 oder mehrfach vorhanden sind, kann ich recht fix in der Variablenentabelle von WinCC Flex die Variablenen setzen. Bei einer einmaligen Softwaregeschichte würde ich mir das aber vorher nochmal gründlich überlegen.
 
Ich habe ein "Sicherungs kopie funktion".
Wenn auf der HMI ein Taster "Daten sichern" gedrucht wird, werden alle wichtige Instanz-daten in ein Sicherungs-DB Kopiert.
Und umgekehrt gibt es ein Taster "Daten holen", om die Werten von Sicherungs-DB in alle Instanz-DB's zu kopieren.

Ich habe reserviert "Objekte" von 1 bis 200, und pro Objekt kann dann z.b. 4 Timer Sollwerten, und 10 Zahl-Werten gesichert werden.
 
ich mache das ähnlich wie Jesper, jedoch lege ich die Daten als Rezept in der HMI ab. Also habe ich meine Parameter in den Instanzdaten liegen. Globaldatenbausteine verwende ich nicht (das ist für mich eine barbarische Unsitte aus S5-Zeiten). Früher habe ich auch mal die Parameter als Startwerte in der Deklaration eingetragen - seit aber bei Flex grundsätzlich Rezepturen vorhanden sind und ich deren Nutzen erkannt habe, gibt es bei mir immer ein Rezept "Maschinendaten".

Anektdote: um den Globaldatenbaustein für eine FM350 zu vermeiden, habe ich schonmal dessen Deklaration als UDT in eine Instanz eingebunden. Nachteil: dieser FB kann keine IN/OUT haben, da der UDT-Teil grundsätzlich ab Adresse 0 liegen muss (Himmel, warum hat das IN/OUT der Siemens nicht auch für FB über den L-Stack abgewickelt?). Also müssen die Signale dem FB über Merker zugeführt werden. Aber ich habe keinen Globalzugriff auf dessen Instanz benötigt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... der UDT-Teil grundsätzlich ab Adresse 0 liegen muss (Himmel, warum hat das IN/OUT der Siemens nicht auch für FB über den L-Stack abgewickelt?). Also müssen die Signale dem FB über Merker zugeführt werden. Aber ich habe keinen Globalzugriff auf dessen Instanz benötigt.

kannst du dir den nicht den Pointer deines UDT umladen, wie hier im Beispiel mit "Einsetzen_Rechts" ist auch ein UDT...?

Verwendung.JPG

aufruf.JPG

gruß helmut
 
da war noch dieser Siemens-FC "CNT2_CTR". Und dem konnte ich, glaube ich, nur die DB-Nummer mitgeben. Wie immer macht Siemens es vor, wie man unsauber programmiert (wobei, was unsauber ist, immer im Auge des Betrachters liegt). Also ist der Globalzugriff auf meinen IDB vorhanden, nur eben nicht von mir, sondern von Siemens im geschützen FC programmiert :rolleyes: [/OT]
 
Ich halte es wie Gerhard K.

@Perf
Ach, ich kann das alles gar nicht mehr hören. Schon gar nicht diesen "S5 ist so Scheiße"-Mist. Programmiersysteme entwickeln sich nun mal, auch die Programmierer. Globale Daten haben nichts mit S5 zu tun, die gibts auch in Codesys. Lokale Daten sind lokal, das sagt der Name ganz eindeutig. Schade daß Step7 es zuläßt, daß man in den Daten eines FB rumpopelt. Dagegen verblassen sogar die Schmiermerker aus S5-Zeiten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
sehr interessantes thema!
bin da auch recht geteilter meinung...

also ich sehe das so:

Vorteile von datenhaltung in globaldbs gegeüber idbs:
- man findet über den querverweise alle zugriffe (die im jeweiligen fb findet man nicht)

- es ist sauberer weil nicht aus irgendwelchen bausteinen von aussen auf idbs zugregriffen wird

- die kopplung zur visu ist besser, erstens kann dem visuprogrammierer ein koppeldb gegeben werden in dem er alles findet, zweitens ist die anbindung schneller weil weniger einzelne blöcke gelesen werden müssen.




vorteile von parametern in idbs:
- es kann wesentlich modularerer gearbeitet werden, benötige ich im projekt die standartfunktion XY, dann rufe ich den fb mit db auf und fertig! wenn ich dann diese variablen erst noch in einem global db anlegen muss, und ggf. auf dinge wie "schreiben von sps und visu" achten muss, dann wird das manchmal sehr fummelig...

- die bilder für die visu können ebenso standartbilder sein, da die variablen immer die selben sind.

- visu aufwand kann reduziert werden, wenn diese standartfunktionen öfters benötigt werde, dann nur noch ein bild mit indirekter db adresse.



also schöner finde ich die modulare lösung mit den parametern im idb.
aber bei proejkten mit vielen sps und somit vielen zugriffen auf kleine blöcke kann dabei die kommunikation schnell leiden... :-(

daten im sps-programm sollten aber dennoch über global-dbs oder tmp geschobeben werden. habe zwar bei bestimmten Stardarfuktionen auch zugriffe auf idbs, zb gibt es für jede betriebsart einnen FB welcher eine struktur "OUT" im statbereich hat, die signale dort werden in einem anderen bautein mit den aktoren verknüpft. hier fände ich es zu aufgeblasen und unperformant 40 ventile oä an eine schnittstelle zu parametrieren...

aber so richtig 100% zufrieden bin ich mit meiner lösung auch nicht, also würde ich mich auch über etwas erfahrungsaustausch zu dem thema freuen.


wegen der sicherung der dbs, also ich kopiere mit die dbs vor jeder änderung aus der cpu ins projekt. wenn die struktur nicht verändert wurde bzw. das immer geamcht wird, dann geht auch die symbolik nicht verloren!
 
Bei uns hat sich die Modulare Bauweise etabliert, wir gliedern immer alles in Funtionsbaugruppen und schieben die Daten in die Instanz. Wenn ich die Daten Remanent brauche benutzte ich Rezepte in der HMI und exportiere die gegebenenfalls noch als CSV. Das ermöglicht den Kunden später noch einmal eine schnelle Datensicherung mit einen USB-Stick oder ähnlich.
Wenn ich etwas am Programm ändere und die Struktur erweitere, passt es trotzdem mit dem Rezept immer überein.
Nachteil ist natürlich das die Änderung nicht immer im laufenden Betrieb machbar ist.

Die ganzen in die Instanz zu verlagern, ist daraus enstanden, schneller herunter programmieren zu können und die Daten nicht erst im Programm suchen zu müssen, Mann hat Sie übersichtlich in Bausteinkopf.

Jede Programmiertechnik hat natürlich seine vor und Nachteile, jeder sollte sehen wie er in seiner Anwendung am besten damit klarkommt.
Bei unseren Maschinen ist es nicht so wesentlich im laufenden Betrieb Änderungen machen zu können, bei einem anderen wird es so sein das kein Maschinenstillstand geduldet wird.
 
...
- man findet über den querverweise alle zugriffe (die im jeweiligen fb findet man nicht)
...
Die lokale Verwendung - finde ich - kann man doch recht einfach mit STRG-SHIFT-F bzw. STRG-SHIFT-B nachverfolgen.

Ein Nachteil eines Visu-Koppel-DB: es ist nicht so leicht möglich, dass sowohl das Programm wie auch die HMI auf eine Variable schreibend zugreift. Jetzt werden vielleicht einige fragen: "wozu das?" und möglicherweise schon nach Steinen greifen, um dann auf mich zielen zu wollen. Also ein einfaches Beispiel: die SPS zählt die Restzeit irgendeiner Eieruhr herunter. Wenn mir der Wert in einem E/A-Feld angezeigt wird, kann ich als Bediener eingreifen, entweder den Kochprozess starten, die Restzeitdauer währenddessen verstellen oder auch abbrechen (in meiner täglichen Praxis handelt es sich um dynamische Nullpunkte von Drehgebern, die auf diese Art und Weise kalibrierbar werden).

Ach ja, diese Aussage:
- es kann wesentlich modularerer gearbeitet werden.
kann ich nur nochmals unterstreichen.

@Ralle: wg. S5-Sch... - sorry :oops:
 
äähhh, hab ich das überlesen??? wenn ja, tschuldigung ...

doch, stimmt, hier stand es:
... und ggf. auf dinge wie "schreiben von sps und visu" achten muss, ...

und da ich zwischendurch den Post #10 vom Helmut gelesen habe, frage ich mich, warum der mich noch nicht auf seiner Freundschaftsliste hat ...

will sagen: genauso, wie der Helmut das macht, genauso machs ich, mitsamt der Einschränkung, dass bei IDB-Strukturänderung halt nunmal ein Stopp notwendig wird und ggf. auch die Visu vor dem Rückspielen des Rezepts aktualisiert werden muss.
 
Zuletzt bearbeitet:
und da ich zwischendurch den Post #10 vom Helmut gelesen habe, frage ich mich, warum der mich noch nicht auf seiner Freundschaftsliste hat ...

...hallo Perfekter, jetzt schau doch noch einmal richtig in deiner Liste richtig nach...:ROFLMAO:

Ich bedanke mich für die Anfrage und nehme das gerne an :D

gruß helmut
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
hier vielleicht noch ein Beispiel für "Visu-Daten in der Instanz" :
Ich habe verschiedene FB's für Aufzeichnung von Kurvendaten unterschiedlicher Charakteristik und anschließender Auswertung. Diese Kurvendaten werden natürlich mit dem FB in seiner Instanz aufgenommen und hinterher der Visu zur Verfügung gestellt. Auf diese Weise kann ich eine gute "Kapselung" der Daten erreichen. Arbeitet dieser FB mit parameterierbaren Grenzwerten, so beschreibe ich hier i.d.R. auch die Instanz-Daten (auf die der FB sowieso nur lesend zugreift). Alle Maschinen-Parameter werden (da ich hauptsächlich RT-Visualisierungen mache) auf der Festplatte des Visu-PC's als CSV-Datei abgespeichert. Dadurch kann ich auch einen gelöschten I-DB wieder "resturieren". Auswerte-Info's an das weitere Programm übergebe ich mittels der Schnittstelle (i.d.R. als OUT).

Bestandteile meines Beitrages sind hier aber auch schon genannt worden ... ;)

Gruß
LL
 
Wie kann man es dennoch sauber möglich machen, auch wenn es etwas umständlich ist?

Gar nicht. Man kann eine IDB nicht sperren für Schreibzugriffe, weder von der HIM noch vom FB aus.
Daher sind die Daten nicht wirklich konsistent.
Es ist kein guter Stil, IDBs für etwas anderes verwenden außer für den FB.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... Es ist kein guter Stil, IDBs für etwas anderes verwenden außer für den FB.

Will ich doch auch gar nicht, deshalb frage ich ja wie man es mit Visu - Koppel - DB dennoch hin bekommen kann.
Könnte man nicht ein Handling für das Schreibrecht einführen? Eine Absprache zwischen SPS und Visu quasi?
 
Könnte man nicht ein Handling für das Schreibrecht einführen? Eine Absprache zwischen SPS und Visu quasi?

Hallo,
klar ... kann man.
Du könntest z.B. einen Bereich erstellen, in den die Visu hineinschreiben kann. Dort schreibst du deinen neuen Wert hinein. Die SPS vergleicht nun, ob sich dieser Wert verglichen mit dem, mit dem sie arbeitet (oder den, den sie bereits kennt), geändert hat und verfährt dann entsprechend.

Gruß
Larry
 
Will ich doch auch gar nicht, deshalb frage ich ja wie man es mit Visu - Koppel - DB dennoch hin bekommen kann.
Könnte man nicht ein Handling für das Schreibrecht einführen? Eine Absprache zwischen SPS und Visu quasi?

Ich mach dafür üblicherweise einen INOUT UDT im FB. An diesen hänge ich einen DB der für HMI, übergeordnete Bedienstation etc. zuständig ist.
Geschrieben wird immer ein Wert. Wenn dieser verarbeitet wurde dann steht im Datenpunkt wieder 0 Drin.

Also Betriebsart setzen. Schreibe z.B. 3 für Automatik in den Datenpunkt (egal von wem) Baustein nimmt das entgegen, schaltet um auf Automatik (3 im RückmeldeDB) und setzt den BefehlsDBW wieder auf 0 zurück.

Das gilt übrigens auch für Sollwerte.
Nachteil für alles brauch ich immer mindestens 2 Speicherzellen.

Manchmal nehme ich auch verschiedene Befehlsarten auf einer Speicherzelle entgegen.
1,2,3 für Hand,Uhr,Auto und 4,5 für Ein,Aus die Betriebsart wird dann aber auf einer anderen Speicherzelle zurückgemeldet als der Zustand (Ein,Aus)

So habe ich übrigens auch gleich die über Kommunikationswege wie S7Verbindung die Befehlsübergabe im Griff, wenn was anderes als 0 drin steht wird der gesamte Block einmal übertragen (inkl. Der Stellen die 0 drin haben, der DB wird dann auf der Masterstation nach übertragung wieder genullt) und danach ist wieder Ruhe und andere Befehlsgeber können wieder drauf schreiben.

mfG René
 
Zurück
Oben