Erweiterung Instanz-DB´s

[momo99]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich soll relativ kurzfristig ein S7-Programm erweitern. Im Programm (vor einiger Zeit von anderer Firma erstellt) wird viel mit Multiinstanzen gearbeitet.

Das System würde ich gerne beibehalten, mein Problem ist, daß ich die Instanz-DB´s erweitern müsste, teilweise ohne zu wissen wie die Werte verarbeitet werden. Handelt es sich bspw. um Eingabewerte, die ich mir dann überschreiben würde, wenn ich den erweiterten DB ins AG schreibe?

Wie geht man in diesem Fall am Besten vor?
Ich tendiere dazu, für die Erweiterungen neue FB´s mit der gleichen Funktion (z.B. Analogwerte einlesen) zu erstellen, sodaß ich dann auch neue Instanz-DB´s habe.

Gruss
momo

 

[Ralle]

Du kannst einen Instanz-DB nicht erweitern, indem du direkt an den DB neue Daten anhängst. Du mußt im FB, zu dem dieser Instanz-DB gehört ändern, indem du dort im Variablendeklarationsteil neue Variablen anlegst. Daraufhin wird dann beim Speichern Step7 einen Warnung geben. Im FC/FB, der den betreffenden FB+IDB aufruft kann man dann ebendalls über Abspeichern eine Meldung erhalten, daß ein neuer IDB erzeugt werden muß. Diese bestätigen und der IDB wird erzeugt. Danach FB+IDB+aufrufenden FC/FB in das AG übertragen.

Je nachdem, wie der Programmmierer arbeitet, kann es sein, daß ohne Probleme der IDB geändert werden kann. Wenn aber von außen auf den IDB zugegriffen wird (von irgendwo aus dem Programm heraus) oder per indirekter Adressierung oder per Rezept von WinCCFlex aus, dann hast du Probleme. Du mußt dann heraufinden, wer, was am IDB manipuliert und diese Adressen/Zugriffe entsprechend ändern.

 

[momo99]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Ralle

Wie die Erweiterung funktionieren würde ist klar (im Deklarationsteil des FB).
Wenn ich das aber mache werde ich bei der IB mit Sicherheit Probleme bekommen.
Die Frage ist, wie ihr das normalerweise handhabt (Erweiterung von IDB´s). Ich denke jeden einzelnen Wert in den verschiedenen DB´s zu überprüfen ob er evtl. über die Visu oder sonstwie von anderer Stelle beschrieben wird ist nicht praktikabel...
Bei Global-DB´s hänge ich normalerweise die Erweiterungen Online an den betreffenden DB an, um mir die AG-Daten nicht zu überschreiben.

Die einzelnen FB´s mit den IDB´s für die Programmerweiterung mit neuer Nummer nochmal zu machen gefällt mir zwar nicht. Eine andere Lösung, die mir dann bei der IB keine Probleme macht fällt mir aber auch nicht ein.

Gruss
momo

 

[Thomas_v2.1]

Ich kenne das Problem. Je nach Anlage habe ich da zwei Vorgehensweisen:

1.)
Die alten Parameter in einer Variablentabelle zwischenspeichern und damit nachher wiederherstellen:
Variablentabelle anlegen, und in dieser die Daten aus den später zu ändernden Instanz DB eintragen. Die Daten aus der Spalte "Statuswert" in "Steuerwert" kopieren.
Dann den FB erweitern und die neuen Datenbausteine erzeugen. Datenbausteine in die Steuerung übertragen und dann mit den Daten aus der Variablentabelle die alten Werte in den DBs wiederherstellen.

Nachteil daran ist, dass nach dem Übertragen der Bausteine erstmal die Startwerte drinstehen. Nicht bei jeder Anlage kann man sich das erlauben.

2.)
Umweg über AWL Quelle:
Die relevanten Instanzdatenbausteine aus der Steuerung in einen Offline Programmordner kopieren.
Aus diesen Offline DBs dann eine AWL Quelle generieren. In dieser AWL-Quelle der Instanz-DBs sind auch die Aktualwerte gespeichert.
Z.B.

DATA_BLOCK DB 21
TITLE =
VERSION : 0.0

 FB 11
BEGIN
   rParam1 := 1.110000e+002; 
   rParam2 := 2.210000e+002; 
END_DATA_BLOCK

Wird nun der FB erweitert (z.B. rParam3) so wird diese Variable einmal im FB und an der _gleichen_ Position im DB angefügt.
Am besten lässt man sich den FB in der gleichen AWL Quelle erzeugen.

Wenn man dann die AWL Quelle übersetzt behalten die Instanz DBs die letzten Aktualwerte.

Wenn die CPU dann genug Ressourcen hat um alle Datenbausteine und den FB auf einmal einzubinden klappt das ohne den kleinsten Ruckler

Bei einer kritischen Anlage würde ich die Vorgehensweise evtl. vorher mit PLCSim oder einer Test SPS mal durchspielen.

 

[Thomas_v2.1]

Bei Global-DB´s hänge ich normalerweise die Erweiterungen Online an den betreffenden DB an, um mir die AG-Daten nicht zu überschreiben.

Uh, sowas ist aber extrem böse. Nichts ist schlimmer als ein unterschiedlicher Programmstand offline und auf der CPU.

Mit der Vorgehensweise 2.) von mir kann man das auch anders lösen.

 

[momo99]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Thomas

Nicht falsch verstehen: Der DB wird im Büro angepasst, Online werden dann nur die Erweiterungen eingefügt (in aller Regel überschaubar).

Wenn man es richtig macht hat man einen DB mit gleichem Stand Online und Offline wo auch noch die Parameter stimmen...

 

[Larry Laffer]

Hallo,

Ich denke jeden einzelnen Wert in den verschiedenen DB´s zu überprüfen ob er evtl. über die Visu oder sonstwie von anderer Stelle beschrieben wird ist nicht praktikabel...

wenn die Visu auf die Instanz-Daten zugreift, dann tut sie es normalerweise nicht absolut sondern symbolisch. Änderst du also die Instanz, so werden zumindestens in ProTool oder Flex die Adressen gleich mit verschoben. Hier wäre es nur nötig, das Projekt einmal neu zum Bediengerät zu übertragen.

Bei "sonstwie" sieht das schon anders aus ...
Beim Arbeiten mit Instanzen sollte man eigentlich zusehen, dass die FB's (und deren I-DB's) sich selbst genügen - soll heißen : alle externen Informationen kommen über die Schnittstelle (IN, IN_OUT, OUT) und intern erfolgen keine absoluten Zugriffe. Ist das so, dann kannst du so einen FB problemlos umwursteln, denn nach dem Ändern würde er ja einfach mit den gleichen Informationen wie vorher weiter arbeiten. Das gilt dann natürlich wiederum nicht für das Programm drum-herum. Erfolgen hier absolute Zugriffe auf Adressen des Instanz-DB's (das machen viele sehr gerne), dann haben sich diese ggf. geändert und müssen nachgepflegt werden. Hier gibt es dann zwar auch Tricks sich zu behelfen (Operandenvorrang symbolisch) - das klappt aber auch nur dann, wenn bei dem "unsauberen" noch sauber gearbeitet wurde - ist also auf jeden Fall mit Vorsicht zu geniessen.

Trifft von diesen Dingen etwas auf dein "Baby" zu ?

Gruß
LL

 

[Ralle]

@Larry

Du kennst ja auch die Diskussionen hier, wenn es um Zugriff auf IDB geht. Aus diesen heraus und aus eigenem Erleben würde ich sagen bei mind. 20% solcher Fälle wird es Probleme geben. Bei meinen Anwendungen ganz sicher nie, da ich einmal kaum FB verwende und wenn, dann ohne IDB-Zugriffe von außerhalb des eigenen FB.

 

[momo99]

Zuviel Werbung?
-> Hier kostenlos registrieren

@LL

ProTool oder Flex ist nicht...

Und zu "sonstwie" - ist schwierig, ich weiß ja nicht was sich der Programmierer vor 2 Jahren gedacht hat. Wäre mir also auf alle Fälle zu heiss.

Wie ich das sehe bleiben mir 2 Möglichkeiten:
a) mit neuen FB´s und IDB´s (einfach, schnell, unschön)
b) Lösung mit AWL-Quellen. Ist natürlich schöner aber etwas aufwendig für mich, weil ich ein aktuelles Programm vorliegen habe mit dem ich jetzt arbeite. Ich müsste also die IDB´s alle auf IB dann nochmal auslesen und wie beschrieben verfahren.

 

[Larry Laffer]

@Ralle:
Mit meinem Beitrag wollte ich auch auf keinen Fall den Stoff für neue Grundsatz-Diskussionen liefern. Es ging mit hier lediglich darum für Momo herauszustellen, wo die Problematiken jeweils stecken.
Leider (und das hast du vollkommen Recht) halten sich viele Programmierer nicht an die Sache mit der Kapselung von FB's - ist sogar mir schon mal zu durchgerutscht ...

@Momo:
Aufgrund deines letzten Beitrages sehe ich da für dich nicht so schrecklich viele Optionen - ich fürchte allerdings, dass wenn du die "alten FB's" anpacken willst, du nicht unhin kommst vorher sicher zu stellen, ob und was mit den daten des/der I-DB's noch so angestellt wird ...

Gruß
LL

 

[Panzerknacker]

Hallo zusammen,

ich habe festgestellt das es bei solchen Erweiterungen ganz praktisch ist wenn man das Projekt von "absoluten Operandenvorrang" auf "symbolischen Operandenvorrang" umschaltet, das Projekt dann dementsprechend an allen notwendigen Stellen erweitert und danach eine vollständige Konsistenzprüfung macht. Dabei werden dann alle betroffenen Bausteine aktualisiert, außer natürlich wenn irgendwo etwas indirekt programmiert wurde.

Was das retten der Aktualwerte angeht würde ich vorher die Werte mit dem SFC20 BLK_MOV in einen "Backup-DB" schieben und nach dem Einspielen der neuen FB's und IDB's mit dem SFC20 wieder zurück in den IDB kopieren, wobei dann natürlich auf die geänderten Bereiche geachtet werden muss.

Gruß
Matthias

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dabei werden dann alle betroffenen Bausteine aktualisiert, außer natürlich wenn irgendwo etwas indirekt programmiert wurde.

Gruß
Matthias

Stimmt, daher ist symbolische Adressierung nicht das Allheilmittel für bzw gegen alles.

@Larry

Du kennst ja auch die Diskussionen hier, wenn es um Zugriff auf IDB geht. Aus diesen heraus und aus eigenem Erleben würde ich sagen bei mind. 20% solcher Fälle wird es Probleme geben. Bei meinen Anwendungen ganz sicher nie, da ich einmal kaum FB verwende und wenn, dann ohne IDB-Zugriffe von außerhalb des eigenen FB.

Da gebe ich dir absolut Recht. Ein InstanzDB ist ein Datenspeicher für einen Funktionsbaustein, nicht mehr und nicht weniger.
Es ist absoult fatal, wenn Daten ausserhalb des FB geändert werden oder wenn irgendwo auf die Daten zugriffen wird und die Herkunft in der CrossRef nicht zu finden ist.



bike

 

[Thomas_v2.1]

Es ist absoult fatal, wenn Daten ausserhalb des FB geändert werden oder wenn irgendwo auf die Daten zugriffen wird und die Herkunft in der CrossRef nicht zu finden ist.

- Warum ist das fatal?
- Wo ist der Vorteil wenn nach euer Vorgehensweise alles globale Variablen sind, wo jeder wie er will drauf rumfuhrwerken kann?
- Warum sollte ein Zugriff auf einen Instanz-DB in der Querverweisliste nicht auftauchen?

 

[bike]

- Warum ist das fatal?
- Wo ist der Vorteil wenn nach euer Vorgehensweise alles globale Variablen sind, wo jeder wie er will drauf rumfuhrwerken kann?
- Warum sollte ein Zugriff auf einen Instanz-DB in der Querverweisliste nicht auftauchen?

Globale Daten, wenn diese benutz oder verändert werden kann durch Bereichsprüfung Unsinn vermieden werden. Die Bereiche bei einem DI sind vom FB abhängig.
Wenn Daten eines FB zusätzlich ausserhalb des FB beeinflusst werden ist die Funktion des FB nicht mehr zuverlässig und seine Funktion ist nicht mehr reproduzierbar.
Ich weiss, dass die Meinungen darüber auseinander gehen, doch wer echte modulare Funktionen, die in verschiedenen Projekten genutzt werden, schreibt wird bestimmt nicht auf DI zugreifen.

Jeder kann so programmieren wie er will, doch es macht Sinn sich an die Regeln und Vorgaben vom Hersteller der Software zu halten.

bike

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zum Thema Daten Retten bei DB-Erweiterung hab ich meist folgendes gemacht (funktioniert allerdings nur, wenn gerade keine Produktion):
Vorbereitung:
- Kopie von original-DB erstellt (z.B. DB101 --> DB1101)
- original-DB offline verändert
Vor Ort:
- Not-Aus rein und warten bis alles steht
- Kopie von original-DB (DB1101) auf AG laden
- im OB1 einen Schaufelauftrag rein (SFC20), der den Inhalt vom original-DB (der ja Online noch vorhanden ist) in die Kopie des original-DBs kopiert (also z.B. 120 Bytes von DB101 --> DB1101)
- unmittelbar nach diesem Schaufelauftrag BEA (Bausteinende) ins Programm - sodass nichts mehr im OB1 bearbeitet wird, was mir die originaldaten beinflussen kann
- OB1 laden und kontrollieren, ob SFC20 RetVal = 0 liefert
- SFC20-Aufruf(e) auskommentieren und OB1 erneut laden
- modifizierten original-DB ins AG laden (DB101)
- nun an Stelle des vorherigen SFC20-Auftrages Schaufelaufträge in die entgegengesetzte Richtung in den OB1 rein (je nachdem wie umfangreich die Änderung war kann ein SFC20-Aufruf genügen - in Deinem Fall, wenn einzelne Instanzen ihre Längen verändert haben, wirst Du wohl viele kleinere SFC20-Schaufelaufträge mit nun versetzten Startadressen benötigen)
- OB1 laden und kontrollieren, ob die Daten nun dort sind wo sie hingehören
- Schaufelaufträg aus OB1 entfernen, BEA aus OB1 entfernen, OB1 laden
- kopie von original-DB aus AG löschen

Ich hoffe diese Vorgangsweise ist einigermaßen verständlich.
Auf diese Art und Weise hab ich schon diverse Programmdaten über gröbere Strukturelle DB-Änderungen gerettet - je nachdem wie man das zurückschaufeln realisiert, lassen sich auch gröbere strukturelle Änderungen und sogar Änderungen am Datenformat realisieren (musste z.B. mal einen kompletten Programmspeicher mit 40 Datensätzen in ein neues Format umbauen, ließ sich mit ein bisschen AWL-Code und einer Schleife problemlos erledigen)
Je nachdem, wie komplex die Instanz-Änderungen sind, und wie heikel die enthaltenen Daten sind, kann es auch reichen, wenn man nur einzelne Anlagenteile stilllegt bzw. nur einzelne FCs/FBs im OB1 auskommentiert.

Sicherheitshalber würde ich die Visu stilllegen (bzw. von der SPS abkoppeln), während Du die Änderungen an der SPS machst - Du musst davon ausgehen, dass Die Visu zumindest für einige Minuten ungültige bzw. sehr seltsame Daten liest, das kann schon mal Skripte durcheinanderbringen bzw. Variablenarchive versauen.

mfg Maxl