# Seiteneffekte bei externem Zugriff auf Instanzdatenbaustein? (SCL)



## Horst-Kevin (27 Juni 2012)

Hallo,

ich arbeite mit Step 7 V 5.5 an einer Steuerung, die überwiegend in SCL implementiert ist.
Gegeben sei z.B. FB10 mit zugehörigem Instanzdatenbaustein DB10. Mit Hilfe der
Symboltabelle sei für DB10 der symbolische MeinDB zugewiesen.

Abweichend von verschiedenen Diskussionsbeiträgen gibt es jedoch keine offensichtlichen
Probleme, wenn ich aus einem/r anderen FB/FC auf Variable/Elemente von DB10 bzw.
 MeinDB zugreife. Änderungen in dem Datenbaustein, die durch eine FC erfolgen, lassen
sich auch gut beobachten.

Gibt es Seiteneffekte, die zu einer Dateninkonsistenz führen können, aber bei meinem
Programm bislang bloß nicht aufgetreten sind?

Oder wird nur aus Gründen sauberen Programmierstils davon abgeraten, auf die (lokalen)
 Variable eines Instanzdaten von außerhalb zuzugreifen, ohne dass es hierfür einen
technischen Grund gibt?

Besteht eine Möglichkeit, Step 7 anzuweisen, externe Zugriffe auf Instanzdatenbausteine
mit einer Fehlermeldung abzulehnen?

Gruß,
Horst-Kevin


----------



## Larry Laffer (27 Juni 2012)

Hallo,
diese Vorgehensweise ist aus meiner Sicht absolut unsauber.
Begründung :
Änderst du den FB10, was zu einem geänderten Aufbau der Instanz desselben führt, arbeiten dadurch alle nicht neu "compilierten" Bausteine, die diese Instanz "quer" verwenden, von da an fehlerhaft. 
Jetzt darauf zu verweisen : "da passe ich schon auf" halte ich für fragwürdig, denn ich weis, dass einem da ganz schnell mal was "durchrutschen" kann.
Ganz grundsätzlich ist es aber nur eine Frage des Stils.

Gruß
Larry


----------



## Horst-Kevin (27 Juni 2012)

Das gleiche Problem kann aber bei einem globalen Datenbaustein auch auftreten, wenn nur einige FB/FC, die darauf zugreifen, aktualisiert werden.
Als Programmierer weiß man lediglich: "Achtung, das ist ein globaler DB, auf den jede Komponente zugreifen darf!" ("darf" im organisatorischen und nicht technischen Sinne).

Grundsätzlich ist es bei uns so, dass ich sehr häufig das gesamte Projekt neu übersetze und dabei sehr zügig Konsistenzprobleme entdecke. Leider macht das aber nicht jeder Mitarbeiter so...

Der direkte Zugriff auf Instanz-DB soll ja auch nicht die Regel sein. Im konkreten Fall geht es darum, dass beim Weitertakten während des Produktionszyklus einige Zähler bzw. Indizes inkrementiert werden müssen. Die entsprechenden Datenstrukturen, die durch die Indizes adressiert werden, sollen aber nur in einem bestimmten FB zur Verfügung stehen und nicht direkt aus anderen FBs verwendet werden. Da das Weitertakten in mehreren Ausführungspfaden erfolgen kann, soll es in eine FC ausgelagert werden. In dieser FC sieht man sofort, welche Indizes davon betroffen sind.
Dadurch, dass sich die Mechanik der Maschine auch noch in der Erprobung befindet und gelegentlich umgebaut wird, verschieben sich hin und wieder auch bestimmte Schritte um einen Takt. Bei solch einer Anpassungen muss man also nur die FC und die Stelle, an der die Anfangswerte der Zähler gesetzt werden, betrachten. Die Ablaufsequenzen der Antriebe befinden sich (leider? glücklicherweise?) außerhalb der SPS und werden separat geladen (Python-Skript, das per pyModbus und Modbus-TCP/RTU-Gateway auf die Motorsteuerungen zugreift).

Die FC greift damit zwar recht häufig auf den Instanz-DB zu, aber außer dem FB, um dessen Instanz-DB es sich handelt, niemand. Eventuell wird es eine weitere FC geben, die Inhalte des Instanz-DB auswertet und daraus Daten für (globale!) DB der Visualisierung und andere Anlagenteile generiert.

Natürlich könnte man auch von vornherein nur auf den globalen DB arbeiten, die z.B. für die Visualisierung verwendet werden, jedoch bestünde hier der gewaltige Nachteil, dass Erweiterungen des globalen DB auch in der Visualisierung und anderen Anlagenteilen nachgezogen werden müssen, was die Angelegenheit sogar noch viel fehlerträchtiger machen würde. Außerdem würden damit mehr Implementierungsdetails eines FB in eine "öffentliche" Schnittstelle, nämlich die globalen DB, wandern als sinnvoll.

Aber meine eigentliche Frage, ob es einen technischen Grund für die Vermeidung externer Zugriffe auf Instanz-DB gibt, wurde durch Deine Antwort hinreichend beantwortet.

Gruß,
Horst-Kevin


----------



## JesperMP (27 Juni 2012)

Ich arbeite problemlos in dise Weise.
Z.B.:
"Conveyor32".Command.Start := "Group3".StartupCommand ;
Wobei "Conveyor32" ist ein IDB.

Das Thema ob es 'erlaubt' ist IDBs zugreifen ausserhalb von die dazugehörende FBs wurde schon heftig diskutiert. 
Meiner Meinung nach, fehlt es bei S7 ein konzept für globale und lokale Daten. IDBs sind nicht dasselbe wie lokale Daten. (und die "L" Daten sind nicht lokale Daten, sondern temporäre Daten). Wäre schön wenn es wirklich globale und lokale Daten gäbe, aber leider ist das nicht so.

Ich sehe es einfach. Egal FB+IDB oder Shared DB oder UDTs, mann kan frei Änderungen in den Deklarationsteil machen wenn das Anlage oder der Machine nicht in Betrieb ist. D.h. nicht in Betrieb genommen oder es gibt eine Produktionspause.
Wenn man Änderungen in den Deklarationsteil macht, dann muss man ein Bausteinkonzistenzcheck durchführen, bevor man den kompletten Program transferiert.
Gibt es Rezepte, oder Einstellungen, die man auch nach einen Programtransfer behalten will, müssen sie in eine andere weise gespeichert werden. Z.B. durch den HMI.
Wenn man nicht Änderungen in den Deklarationsteil macht, gibt es keine Einschränkungen !

Es geht auch Änderungen in den Deklarationsteil in laufende Betrieb durchzuführen, aber das ist für 'geübte'


----------



## Ralle (27 Juni 2012)

JesperMP schrieb:


> Meiner Meinung nach, fehlt es bei S7 ein konzept für globale und lokale Daten. IDBs sind nicht dasselbe wie lokale Daten. (und die "L" Daten sind nicht lokale Daten, sondern temporäre Daten). Wäre schön wenn es wirklich globale und lokale Daten gäbe, aber leider ist das nicht so.



Das verstehe ich nicht! Weil man etwas machen kann und der Compiler nicht meckert oder gar die Arbeit verweigert, ist es ja noch immer nicht richtig. In ein paar ganz wenigen Fällen, ist es immer mal sinnvoll, so etwas zu machen, aber das sollte die Ausnahme sein. Wenn man den IDB als Lokal betrachtet, dann sind Zugriffe von "außen" schlichtweg nicht möglich, auch wenn es funktioniert. Dass das in Pascal, C usw. so ist, hat schon einen Sinn.
Fakt ist eins, machen kann man viel, aber nachfolgende Programmierer, die euren Code warten müssen, werden euch verfluchen.


----------



## JesperMP (27 Juni 2012)

Ralle schrieb:


> Das verstehe ich nicht! Weil man etwas machen kann und der Compiler nicht meckert oder gar die Arbeit verweigert, ist es ja noch immer nicht richtig. In ein paar ganz wenigen Fällen, ist es immer mal sinnvoll, so etwas zu machen, aber das sollte die Ausnahme sein. Wenn man den IDB als Lokal betrachtet, dann sind Zugriffe von "außen" schlichtweg nicht möglich, auch wenn es funktioniert. Dass das in Pascal, C usw. so ist, hat schon einen Sinn.
> Fakt ist eins, machen kann man viel, aber nachfolgende Programmierer, die euren Code warten müssen, werden euch verfluchen.


Erklär es doch WARUM anstatt nur Pascal und C zu nennen.
Bei Pascal und C gibt es lokale und globale Daten. Bei IEC61131-3 gibt es auch Local und Global "scope".

Und, es kommt ja eine neue Generation S7. Ich verstehe nicht warum Siemens nicht den Gelegenheit genutzt hat S7 mit lokal und global Scope zu erweitern.


----------



## Ralle (27 Juni 2012)

JesperMP schrieb:


> Erklär es doch WARUM anstatt nur Pascal und C zu nennen.
> Bei Pascal und C gibt es lokale und globale Daten. Bei IEC61131-3 gibt es auch Local und Global "scope".
> 
> Und, es kommt ja eine neue Generation S7. Ich verstehe nicht warum Siemens nicht den Gelegenheit genutzt hat S7 mit lokal und global Scope zu erweitern.



Keine Ahnung, warum, ich denke mal, das rührt aus alten Zeiten und wurde immer mitgeschleppt. Eine Konzeptänderung hätte sicher zu fehlender Abwärtskompatibilität geführt und wir hätten dann auch getobt. Ich hab damit kein Problem, IDB sind tabu, keine externen Zugriffe (Ausnahme evtl. vollkommen in sich abgeschlossenen Bausteine, wie der FB125 von Siemens, bei welchem die HMI den IDB nutzt.) Will ich Daten vom FB haben oder diesem geben, dann entweder über die Schnittstelle des FB oder über einen Global-DB, falls es zu viele Daten werden. 

PS: Jesper, du adressierst ja immerhin schön komplett die IDB-Daten, ich kenne Programme, das werden Daten per indirekter Adressierung zwischen den Bausteinen hin- und hergepokt, da findest du nichts und weißt auch nicht, warum sich Daten ändern. Wenn dann auch noch die HMI Daten in den IDB schmiert, viel Spaß...


----------



## JesperMP (27 Juni 2012)

Ralle schrieb:


> Ich hab damit kein Problem, IDB sind tabu, keine externen Zugriffe (Ausnahme evtl. vollkommen in sich abgeschlossenen Bausteine, wie der FB125 von Siemens, bei welchem die HMI den IDB nutzt.) Will ich Daten vom FB haben oder diesem geben, dann entweder über die Schnittstelle des FB oder über einen Global-DB, falls es zu viele Daten werden.


Was passiert dann, wenn du den FB Schnittstelle änderst, oder ein Global-DB Änderst ? Es ist dasselbe 'Problem'.



Ralle schrieb:


> PS: Jesper, du adressierst ja immerhin schön komplett die IDB-Daten, ich kenne Programme, das werden Daten per indirekter Adressierung zwischen den Bausteinen hin- und hergepokt, da findest du nichts und weißt auch nicht, warum sich Daten ändern. Wenn dann auch noch die HMI Daten in den IDB schmiert, viel Spaß...


Du findest in meiner Programme fast keine indirekte Addressierung in STL über AR1 oder AR2 ("tabu" wenn du willst). Und das freut meine Kollegen die meine Programme instandhalten muss. Indirekte Adressierung passiert bei mir fast immer in SCL. Eine nebenvorteil ist das es wird Referenzdaten gebildet, so das diese indirekte Addresierungen in den Querverweis inkludiert sind.


----------



## Ralle (27 Juni 2012)

JesperMP schrieb:


> Was passiert dann, wenn du den FB Schnittstelle änderst, oder ein Global-DB Änderst ? Es ist dasselbe 'Problem'.



Bei globalen DB kann ich entscheiden, ob ich Daten einfüge (alles verschiebt sich), Daten anhänge oder schon von vorn herein Bereiche als Reserve deklariere (nichts verschiebt sich). Wenn ich einen FB ändere, reicht schon ein zusätzlicher IN, alles verschiebt sich. Dann muß man tatsächlich die HMI nachziehen und das gesamte Programm gleich mit.


----------



## JesperMP (27 Juni 2012)

Ralle schrieb:
			
		

> Bei globalen DB kann ich entscheiden, ob ich Daten einfüge (alles verschiebt sich), Daten anhänge oder schon von vorn herein Bereiche als Reserve deklariere (nichts verschiebt sich). Wenn ich einen FB ändere, reicht schon ein zusätzlicher IN, alles verschiebt sich. Dann muß man tatsächlich die HMI nachziehen und das gesamte Programm gleich mit.


Also, kein Unterschied zu wenn du die IDB Daten direkt zugreifen wurdest.

Ich verstehe nicht warum du findest das direkten zugang zu IDBs in Code tabu ist, aber für den HMI ist es erlaubt ??
Genau das tu ich auch nicht.


----------



## Thomas_v2.1 (27 Juni 2012)

Vielleicht sollten wir mal vom zu diesem Thema üblichen Diskussionstil abgehen.
Denn üblich ist es dass mal wieder eine Seite total dafür ist und eine andere total dagegen. Die eine Seite gibt fleißig "Danke" für alle Pro-Posts, und vice versa. Dann können wir auch jedes mal eine Abstimmung machen.

Außerdem sind auch die Anlagen sie mit Step 7 programmiert werden zu unterschienlich, als dass man hier eine allgemeingültige beste Lösung abgeben kann.
Vergleiche mit Pascal oder C kann man auch nicht ziehen, da dieses Problem ein alleiniges Simatic Step7 Problem wegen der absoluten Adressen ist. Bei Codesys/Twincat gibt es diese Problem z.B. überhaupt nicht.
Ich will die Step7-Struktur jetzt nicht prinzipiell in Frage stellen, denn sie ja sicher auch ihre Vorteile.
Aber es ist nunmal so wie es ist, und wir müssen uns damit abfinden und das beste daraus machen.

Wir könnten als Diskussionsgrundlage ja mal eine einfache Aufgabenstellung geben. Zu dieser Aufgabe kann dann jeder seine Programmstruktur skizzieren.
Es geht dabei also nicht um das ausprogrammieren, sondern um eine grobe Übersicht der Programmstruktur.
Zu den einzelnen Lösungen gibt es dann entsprechende Punkte die dafür, und andere die dagegen sprechen.

Vorschlag für eine Aufgabenstellung:
- 2 Analogmessungen
- 3 Antriebe mit Frequenzumrichter
- Automatik in der die Messwerte und der Messwertzustand ausgewertet werden müssen, und
  in der der Status der Antriebe (Störung) ausgwertet werden muss, und Befehle an die Antriebe (mit Sollwert) gegeben werden sollen
- Visualisierung der Antriebe und Messungen über übliche S7-Kommunikation (z.B. wie WinCC flexible)

Das Lösungskonzept könnte man entweder in textlicher Form beschreiben, oder mit einer Grafik darstellen.
Ich habe mal ein Beispiel so einer Skizze angehängt.

Dann hätte man eine Diskussionsgrundlage und weiß von welchem Konzept der andere spricht.
Meinungen dazu?


----------



## Ralle (28 Juni 2012)

JesperMP schrieb:


> Also, kein Unterschied zu wenn du die IDB Daten direkt zugreifen wurdest.
> 
> Ich verstehe nicht warum du findest das direkten zugang zu IDBs in Code tabu ist, aber für den HMI ist es erlaubt ??
> Genau das tu ich auch nicht.



Du hast mich nicht richtig verstanden, ich sprach von absoluter Ausnahme und von komplett in sich geschlossenen Bausteinen mit rel. großen Datenmengen, wie z.Bsp. der FB126 von Siemens. Ich hab einen ähnlichen Baustein für eine PNOZ-Multi von Pilz, da mache ich das auch so, alles andere wäre Megaplatz- und Zykluszeitverschwendung. Aber das ist auch schon mein einziger Baustein, der so arbeitet. 

Wenn du keinen Unterschied siehst, (siehe dein Zitat im letzen Post), dann sag ich auch nichts mehr zum Thema.

@Thomas
Nette Idee, aber da hab ich im Moment einfach nicht die Zeit dazu. Interessant aber immerhin, vielleicht finden sich ja Teilnehmer. Wir hatten ja mal einen Programmierwettbewerb ... 

Ich weiß schon, dass sich zu diesem Thema nie eine Einigung erzielen läßt, aber ich bin da ohnehin nicht zu Kompromissen bereit, ich habe einfach schon zu viel miesen Code nach Fehlern durchsucht und zu oft war das Rumgepoke im IDB eine der Ursachen. Ansonsten ist mein Code eh altmodisch!   Aber immerhin, meißt funzt er.


----------



## Paule (28 Juni 2012)

Horst-Kevin schrieb:


> Oder wird nur aus Gründen *sauberen Programmierstils *davon abgeraten, auf die (lokalen)
> Variable eines Instanzdaten von außerhalb zuzugreifen, ohne dass es hierfür einen
> technischen Grund gibt?


Na wenn das als Programmierer kein stichhaltiger Grund ist, dann weiß ich auch nicht.


----------



## JesperMP (28 Juni 2012)

Ralle schrieb:


> Du hast mich nicht richtig verstanden, ich sprach von absoluter Ausnahme und von komplett in sich geschlossenen Bausteinen mit rel. großen Datenmengen, wie z.Bsp. der FB126 von Siemens.


Ich habe deine Einträge sorgfältig gelesen. Du hast geschrieben das "..., IDB sind tabu, keine externen Zugriffe (Ausnahme evtl. vollkommen in sich abgeschlossenen Bausteine, wie der FB125 von Siemens, bei welchem die HMI den IDB nutzt.)"
Also, es ist ein Ausnahme mit Zugriffe auf IDBs.
In dein vorigen Eintrag die ich zitierte hast du nicht geschrieben das Änderungen von Global-DBs oder FB-Schnittstellen war ein Ausnahme 
Soll ich es so verstehen das du machst nie (mit Ausnahmen) Änderungen in Global-DBs, oder in FB-Schnittstellen ?



Ralle schrieb:


> Wenn du keinen Unterschied siehst, (siehe dein Zitat im letzen Post), dann sag ich auch nichts mehr zum Thema.


Ich sah kein Unterschied in den Wirkung auf den rest von das Program, ob man ein Global-DB ändert, ein FB-Schnittstelle ändert, oder den Deklarationsteil von ein FB ändert. Es wird sowieso ein Aktualisierung von den ganzen Program auslösen.

Das du nicht mehr sagen willst ... ich weis nicht ob du nicht vertraust das ich Argumente verstehen kann und akzeptieren will (kann ich und will ich), oder weil du nicht argumentieren kannst oder willst.


----------



## Ralle (28 Juni 2012)

@Jesper
In globalen Daten kannst du ändern was du willst, dazu sind sie da.
Wenn ich einen FB ändere, dann will ich hinterher nicht das komplette Programm inkl. HMI und Programmteile mit indirekter Adressierung (im schlimmsten Fall) abändern.
Stell dir vor, du gehst auf Fehlersuche und stellst fest, in FB100 ist ein Fehler, du beseitigst ihn und baust zusätzlich eine weiter IN-Variable ein. Danach geht in deinem gesamten Programm nichts mehr, inkl. HMI, also suchst du wieder. 
Wenn du in globalen DB änderst, dann hängst du hinten etwas an oder nutze freigelassene Reservebereiche. So etwas kann man im Fb gar nicht sinnvoll machen, der IDB entsteht ja aus IN, OUT, INOUT, STAT.
Also ist es das sauberste, IDB als das zu nutzen was sie immer waren, Daten, die ausschließlich dem FB gehören.


----------



## Larry Laffer (28 Juni 2012)

@Ralle und Jesper:
Ihr werdet euch darüber doch nie einig werden können. Es ist je nach Sichtweise ein philosophisches Thema. Ich sehe es zwar auch wie Ralle und würde es bei mir auch so durchsetzen - aber beim Forum als Missionar tätig sein zu wollen halte ich für sinnlos.
Es ist halt eine Frage des (eigenen) Stils - ich würde mich für die Begründung aber auch an Hochsprachen orientieren ...

Gruß
Larry


----------



## JesperMP (28 Juni 2012)

@Larry:
In Hochsprachen haben die Objekte Daten die durch Encapsulation entweder frei zugänglich (C++ "public") oder nur innerhalb von Objekt zugänglich (C++ "protected") sind.
In IEC61131-3 gibt es auch Globale und Lokale Daten.
In S7 gibt es diese Funktionalität gar nicht.
Ihr sagen: Dann muss man mit S7 sich komplett von Globale Objekt-Daten verzichten.
Ich sage: Dann muss man mit S7 selber die Daten in Local/protected und Global/public trennen, und freiwillig sich begrenzen so das man Global nur die "Globale" Daten addressieren.


----------



## Larry Laffer (28 Juni 2012)

@Jesper:
Ich sage mal so :
Da es ja die duir ganz sicher auch bekannten unliebsamen Randerscheinungen bei diesen Querzugriffen gibt, die einem sofort unterlaufen können wenn man nur einen Augenblick nicht richtig aufpasst, halte ich es (und das gilt für mich und meinen Aktionsbereich und nicht für dich oder irgend jemanden sonst) so, dass ich genau aus dem Grund das eben nicht mache und bei uns auch nicht zulasse - außer im Falle der auch von Ralle schon genannten Ausnahme mit dem "echten" Standard-Baustein (wobei auch das schon wieder eine Inkonsequenz ist - ich weiß). Ich erwarte aber nicht, das irgend jemand im Forum (außer er arbeitet für mich) es mir gleichtut ...

Liebe Grüße
Larry


----------



## Thomas_v2.1 (28 Juni 2012)

Larry Laffer schrieb:


> Da es ja die duir ganz sicher auch bekannten unliebsamen Randerscheinungen bei diesen Querzugriffen gibt, die einem sofort unterlaufen können wenn man nur einen Augenblick nicht richtig aufpasst, halte ich es (und das gilt für mich und meinen Aktionsbereich und nicht für dich oder irgend jemanden sonst) so, dass ich genau aus dem Grund das eben nicht mache und bei uns auch nicht zulasse - außer im Falle der auch von Ralle schon genannten Ausnahme mit dem "echten" Standard-Baustein (wobei auch das schon wieder eine Inkonsequenz ist - ich weiß). Ich erwarte aber nicht, das irgend jemand im Forum (außer er arbeitet für mich) es mir gleichtut ...





Larry Laffer schrieb:


> Die ermittelten Info's werden von mir in der Hauptsache in der Visu ausgewertet / angezeigt. Hier verwende ich dann die Instanz des FB direkt.



Passt irgendwie nicht so ganz zusammen. Wieviele Ausnahmen gibt es denn noch?


----------



## Larry Laffer (28 Juni 2012)

@Thomas:
Wirklich gut - einziger Unterschied zum Step7-Programm : Die Visu kümmert sich bei symbolischen Zugriffe ganz alleine um das glattziehen bei Änderungen - und zwar auf dann noch, wenn ich es mal vergessen habe, neu zu generieren.
Aber schön, dass du dich als aufmerksamer Forums-User wieder mal um das "Haar in der Suppe" bemühst.
Ganz generell gilt aber : "der Weg zur Hölle ist mit guten Vorsätzen gepflastert". ich versuche wenigstens, welche zu haben - die meißten anderen machen nichtmal das ...

Wie dir aber vielleicht aufgefallen ist (oder auch nicht) - ich sprach die ganze Zeit von meiner Sicht der Dinge - nicht von deiner. Du darfst gerne weiterhin "von hinten durch die Brust ins Auge" programmieren - außer du tust es für mich ...

Gruß
Larry


----------



## Ralle (28 Juni 2012)

Ihr dürft nicht vergessen, es gibt auch noch HMI, die nicht von Siemens ist, das wird nichts glattgezogen.


----------



## rostiger Nagel (28 Juni 2012)

Aber LL neu generieren in Flex ist nichts anderes wie eine Bausteinkonsitenzprüfung? Beides 
gehört für mich zum Programmieren dazu ohne kann wirklich auf die Schnauze fallen, selbst mit Globalen DB's, die beim ändern, was in der Praxis vorkommt, sich genauso verhalten wie IDB's


----------

