# Problem: Externer Zugriff auf IDB's



## Approx (30 Dezember 2010)

Hallo.
Ich bin gerade dabei, ein echtes Katastrophen-Step7 Programm (Fremdfirma, nicht mehr greifbar) neu aufzusetzen und zu optimieren. D.h. Leichen entfernen, Symbolik durchkämmen usw.
Habe hier mehrere Sinamics-FB's auf deren jeweilige Instanz-DB's extern in anderen FC's zugegriffen und zugewiesen wird. Sowas finde ich immer heikel und werde es bereinigen. Der Sinamics-FB regelt im Prinzip nur die Kommunikation mit dem FU über SFC14/15, bastelt das Telegramm an den FU zusammen und fieselt die Daten vom FU auseinander.
Als Anhang habe ich mal den Aufruf des Sinamics-FB, dessen zugehörigen IDB und den externen Zugriff auf den IDB am Beispiel des Sollwertes beigefügt.
Mir stellen sich folgende Fragen:
Was passiert eigentlich mit unbeschalteten FB-Eingangsparametern? 
Ist es egal, ob man *vor* oder *nach dem FB-Aufruf* auf die Instanzdaten schreibend zugreift? Musste der Programmierer dieser Grotten-Software Regeln bei der Reihenfolge beachten?

Bin gespannt auf eure Antworten!
Gruß Approx


----------



## Blockmove (30 Dezember 2010)

Approx schrieb:


> Mir stellen sich folgende Fragen:
> Was passiert eigentlich mit unbeschalteten FB-Eingangsparametern?
> Ist es egal, ob man *vor* oder *nach dem FB-Aufruf* auf die Instanzdaten schreibend zugreift? Musste der Programmierer dieser Grotten-Software Regeln bei der Reihenfolge beachten?


 
Solche Dinge findest du in Zusammenhang mit Siemens-Antriebstechnik öfters.
Aber um deine Fragen zu beantworten:
Unbeschaltete Parameter bei einem FB "gibt" es eigentlich gar nicht. Soll heissen: Jedem Parameter ist ein entsprechender Bereich im Instanz-DB zugeordnet. IN-Parameter bleiben auf ihrem Anfangswert, OUT- oder INOUT-Parameter haben den Wert, der ihnen im FB zugewiesen wird.

Der Zeitpunkt des Zugriffs (vor oder nach dem FB-Aufruf) ist natürlich wichtig. 

Gruß
Dieter


----------



## Approx (30 Dezember 2010)

Hallo Dieter,
habe nun zumindest die Eingangsparameter des FB (falls ausserhalb dem IDB zugewiesen) ordentlich an dem FB angetragen. Ist ein bisschen fieselei, aber macht es für die Instandhalter nachvollziehbarer. Zumal es sich um 8 Antriebe handelt.


Blockmove schrieb:


> Der Zeitpunkt des Zugriffs (vor oder nach dem FB-Aufruf) ist natürlich wichtig.


Habe noch anzumerken, daß die Sollwertbildung (FC245, Rampe) im OB35 alle 100ms zugewiesen wird. Hab ich eben auch erst gesehen. Da das zyklische Programm interruptmäßig unterbrochen wird, dürfte es ja *nicht wichtig* sein, ob nun vor oder nach dem FB-Aufruf auf den IDB geschrieben wird. ?!?
Da habe ich mir gleich das beste Beispiel ausgesucht, hihi.
Ich muss aber auch eingestehen, daß die Anlage seit einem Umbau problematisch ist. Derjenige, der das verbrochen hat, ist endlich vom (Stahlwerks-)Hof gejagt und ich versuche nu alles gerade zu biegen...

Jedenfalls vielen Dank.


----------



## Approx (30 Dezember 2010)

Blockmove schrieb:


> IN-Parameter bleiben auf ihrem Anfangswert, OUT- oder INOUT-Parameter haben den Wert, der ihnen im FB zugewiesen wird.


Nochwas: Eigentlich wird im FB gar nicht viel gemacht. Teilweise werden die Sendedaten an den FU nur extern des FB's verhackstückt. Sieht mir ganz so aus, als hätte da jemand einen Siemens-Vorlage-FB genommen und das Know how für die Steuerworte usw. aussen drumherumgebastelt...

Approx


----------



## rostiger Nagel (30 Dezember 2010)

Hallo Approx, 
das FB Eingänge nicht belegt sind muss nicht weiter schlimm, auch wenn
diese dann von andere stelle beschrieben werden, funktioniert das. 
Wichtig ist eigentlich was der Baustein intern damit macht, wird z.b. ein
Wert erwartet und der ist dann nicht beschaltet, kann es dazu führen
das der Gewünschten verknüpfungen oder Berechnungen, nicht das 
Gewünschte Ergebnis liefern.

Wenn ich ehrlich sein soll mach ich das hin und wieder auch, z.b. für einen
Sollwert den führe ich auf die Schnittstelle, beschreibe den aber dann von
der HMI. So habe ich dann die möglichkeit ihn von der HMI oder vom Programm
aus zu beschalten, aber niemals beides.

Keine Angst ich werde euren Hof nicht betreten, von Stahl habe ich keine Ahnung.

guten Rutsch


----------



## Approx (30 Dezember 2010)

Helmut_von_der_Reparatur schrieb:


> Wenn ich ehrlich sein soll mach ich das hin und wieder auch, z.b. für einen
> Sollwert den führe ich auf die Schnittstelle, beschreibe den aber dann von
> der HMI. So habe ich dann die möglichkeit ihn von der HMI oder vom Programm
> aus zu beschalten, aber niemals beides.
> ...


 
Wenn etwas an den FB angetragen ist, dann ist ja gut. Ob nun von Step7 oder von HMI etwas vorgegeben wird, ist ja egal. Mir ging es ja nur darum, das fast nix am FB angetragen war. Alles in diversen Programmteilen über den IDB. Und beim Sollwert war es ja noch einfach! ;-) Der viele Kleinkram mit Quittierungen, Freigabe-bits usw. mach viel Arbeit, weil oft verwendet.

Gruß
P.S.: Wünsche auch schönen Rutsch! Wer glaubt, im Stahlwerk is warm - der irrt!


----------



## Sinix (30 Dezember 2010)

Approx schrieb:


> Sieht mir ganz so aus, als hätte da jemand einen Siemens-Vorlage-FB genommen und das Know how für die Steuerworte usw. aussen drumherumgebastelt...
> Approx



Da gibt es doch einen ganz offiziellen Baustein FB283 von Siemens.
Sogar mit Handbuch...


MfG


----------



## borromeus (30 Dezember 2010)

Also ich finde da ist nichts daran auszusetzen wenn man einen Eingangsoperanden eines FB "extern" beschreibt.

zB der Sollwert in diesem Beispiel...
alternativ muss man ein MW (oder einen anderen DBx.DBWy) verwenden, das auch nicht mehr Klarheit im Programm verschafft.

Wenn man die Symbolik einschaltet heisst die Variable auch gleich sinnvoll.


----------



## borromeus (30 Dezember 2010)

Zitat: Sowas finde ich immer heikel und werde es bereinigen. 
Was ist denn die Alternative? statt dem IDB-Bit einen Merker nehmen und den dann an den FB "klemmen"?

Zitat: Ist es egal, ob man *vor* oder *nach dem FB-Aufruf* auf die Instanzdaten schreibend zugreift? Musste der Programmierer dieser Grotten-Software Regeln bei der Reihenfolge beachten?

Da ist dasselbe zu beachten wie wenn Du das- so wie Du es ja vermutlich ändern möchtest- einen Merker, Merkerwort verwendest.
Der IDB ist nichts böses..... und hat keine besonderen oder fiese Eigenschaften.

;-)


----------



## Approx (30 Dezember 2010)

borromeus schrieb:


> Wenn man die Symbolik einschaltet heisst die Variable auch gleich sinnvoll.


Ironie on/
Echt? Wie geht das? 
/Ironie off 
Leute, hängt euch nicht an meinem "Sollwert"-Beispiel auf. Ich finde das externe Beschreiben von IDB's kacke! Dann soll man sich lieber die Mühe machen, und dem FB etwas Logik verpassen, anstelle im ganzen Programm verteilt hier und da mal nen IDB-Bit zu beschreiben! Ist ja furchtbar sowas.
Ich möchte als Insti den FB-Aufruf im Onlinestatus ansehen, und sofort bescheid wissen!
Approx


----------



## Ralle (30 Dezember 2010)

Ich denke ihr kennt meine Meinung, wenn irgendwie möglich sollte man in keine Weise auf einen IDB zugreifen, das sind interne Daten des FB. Und ja borremeus, dann nimm einen Zwischenmerker in Form einer Temp- oder noch besser einer Globaldatenbausteinvariable. Du hast Recht, im oben gezeigten Fall ist das noch ganz klar und ersichtlich, aber als nächstes wird dann indirekt ein ganzer Bereich umkopiert oder eine Struct, dann findet man das nicht mehr. Alles andere geht natürlich, ist aber extrem unsauber und buggy. Ausnahmen bestätigen die Regel, klar, manchmal hat man Druck oder keine Zeit oder oder oder. 

PS: Nicht zu vergessen --> Änderungen am FB führen zu Verschiebungen im IDW, was böse enden kann, wenn mann von "Außen" Zugriffe auf diesen IDB hat.

@ SPS-Programmierer ohne Furcht und Tadel
Pfui, direkt aus einer HMI auf einen IDB, das ist der Supergau, das findet niemand!


----------



## borromeus (30 Dezember 2010)

Du kannst aber auch den IDB online anschauen, da weisst Du mehr, weil Du auch gleich die STAT variablen siehst und in verschiedenen Fällen siehst was das Teil gerade macht.


----------



## Approx (30 Dezember 2010)

borromeus schrieb:


> Was ist denn die Alternative? statt dem IDB-Bit einen Merker nehmen und den dann an den FB "klemmen"?


Genau das habe ich gemacht. Und zwar aus dem Grund:


> Ich möchte als Insti den FB-Aufruf im Onlinestatus ansehen, und sofort bescheid wissen!


----------



## rostiger Nagel (30 Dezember 2010)

Ralle schrieb:


> @ SPS-Programmierer ohne Furcht und Tadel
> Pfui, direkt aus einer HMI auf einen IDB, das ist der Supergau, das findet niemand!


 

ich weiß ich schäme mich auch :icon_redface:

aber ich mach das trotzdem weiter, weil ich auch faul bin


----------



## Blockmove (30 Dezember 2010)

Ralle schrieb:


> @Hartmut
> Pfui, direkt aus einer HMI auf einen IDB, das ist der Supergau, das findet niemand!


 
*ACK*

Also das muss nun wirklich nicht sein. 

Gruß
Dieter


----------



## Approx (30 Dezember 2010)

borromeus schrieb:


> Du kannst aber auch den IDB online anschauen, da weisst Du mehr, weil Du auch gleich die STAT variablen siehst und in verschiedenen Fällen siehst was das Teil gerade macht.


Vielleicht muss ich mal präzisieren, weil die Diskussion sonst zu nix führt:
Nicht *ICH* muss mit der Software klarkommen (ich kann mir da schon alleine helfen), sondern z.B. der 50-Jährige Schichtelektriker oder der gerade ausgelernte Jungarbeiter...


----------



## Thomas_v2.1 (30 Dezember 2010)

Approx schrieb:


> Leute, hängt euch nicht an meinem "Sollwert"-Beispiel auf. Ich finde das externe Beschreiben von IDB's kacke! Dann soll man sich lieber die Mühe machen, und dem FB etwas Logik verpassen, anstelle im ganzen Programm verteilt hier und da mal nen IDB-Bit zu beschreiben! Ist ja furchtbar sowas.
> Ich möchte als Insti den FB-Aufruf im Onlinestatus ansehen, und sofort bescheid wissen!



Ich greife ab und zu auch mal auf die Instanzdaten zu, vor allem bei Reglerbausteinen. Wenn man Siemens-Bausteine aus dem Modular-PID-Control verwendet kommt man auch garnicht drumherum sowas zu machen.

Damit der FB dann aber nicht nackt ohne Beschaltung dasteht, kann man auch die Parameter mit dem eigenen Instanz-DB beschalten, also so:

```
CALL  "FB_TEST" , "IDB_TEST"
  IN1 :="IDB_TEST".IN1
  IN2 :="IDB_TEST".IN2
  OUT1:="IDB_TEST".OUT1
  OUT2:="IDB_TEST".OUT2
```

Dann klappts auch mit dem Online-Status, und man kann zusätzlich schnell zur Verwendungsstelle springen wenn man auf den Operanden klickt.


----------



## Ralle (30 Dezember 2010)

Helmut_von_der_Reparatur schrieb:


> ich weiß ich schäme mich auch :icon_redface:
> 
> aber ich mach das trotzdem weiter, weil ich auch faul bin



LOL, das mag ich so an dir! *ROFL*


----------



## Sinix (30 Dezember 2010)

Ich glaube eine Diskussion über die Eingangsparameter wird wohl endlos.
Das es möglich ist ist wohl klar. Bei Multiinstanzen ist es ja im Grunde genommen auch nichts anderes. Bei  einem Timer SFB4 kann ja auch irgendwo im Programm stehen "=xxx.IN"

Die Frage sollte lauten, wie kann man es besser machen und vor allem für Instandhalter transparent. Wenn der Eingangsparameter ohnehin extern geschrieben wird, dann wäre doch ideal statt des Eingangsparamter eine statische Variable anzulegen. Dann verwirrt zumindest der nicht belegte Eingang am Bausteinaufruf nicht.


Edit: oder noch besser Thomas v2.1 seine Variante


----------



## borromeus (30 Dezember 2010)

Ralle schrieb:


> Ich denke ihr kennt meine Meinung, wenn irgendwie möglich sollte man in keine Weise auf einen IDB zugreifen, das sind interne Daten des FB. Und ja borremeus, dann nimm einen Zwischenmerker in Form einer Temp- oder noch besser einer Globaldatenbausteinvariable. Du hast Recht, im oben gezeigten Fall ist das noch ganz klar und ersichtlich, aber als nächstes wird dann indirekt ein ganzer Bereich umkopiert oder eine Struct, dann findet man das nicht mehr. Alles andere geht natürlich, ist aber extrem unsauber und buggy. Ausnahmen bestätigen die Regel, klar, manchmal hat man Druck oder keine Zeit oder oder oder.
> 
> @ SPS-Programmierer ohne Furcht und Tadel
> Pfui, direkt aus einer HMI auf einen IDB, das ist der Supergau, das findet niemand!


 
Kann das so nicht bestätigen, man kann eine Software immer schlecht und unübersichtlich programmieren, aber der qualifizierte Zugriff auf IDB Daten gehört m.E. nicht dazu. Alternativ werden nur Daten auf Globaldatenbausteine zwischenrangiert, was in dem konkreten Fall nichts, aber auch gar nichts bringt. 
Wo ist denn bitteschon der Unterschied wenn das oben genannte Bit 20x irgendwo verwendet wird ob es in einem DB steht der am FB hängt, oder gleich das IDB-Bit ist.

Ob die Verwendung eines Bits (schreibender weise) 20x irgendwo im Programm gut ist steht auf einem anderen Papier- ob das bei dieser Software notwendig ist kann ich aber nicht beurteilen und daher auch nicht kommentieren.


----------



## Onkel Dagobert (30 Dezember 2010)

Thomas_v2.1 schrieb:


> ..Damit der FB dann aber nicht nackt ohne Beschaltung dasteht, kann man auch die Parameter mit dem eigenen Instanz-DB beschalten, also so:
> 
> ```
> CALL  "FB_TEST" , "IDB_TEST"
> ...


So ein Programm ist mir in diesem Jahr bei einem Kunden unter gekommen. Beim Übersetzen beisst sich die Katze in den Schwanz. Man kann mit Step7 sehr viel Mist machen, es gibt ja wirklich mehr als genug Möglichkeiten dazu.


----------



## Perfektionist (30 Dezember 2010)

borromeus schrieb:


> ... man kann eine Software immer schlecht und unübersichtlich programmieren, aber der qualifizierte Zugriff auf IDB Daten gehört m.E. nicht dazu.
> ...


Na, da gibt es so Gebote, dass eine Funktionseinheit in sich abgeschlossen (gekapselt) sein sollte. Und Schnittstellen möglichst sparsam und entsprechend offensichtlich sein sollten. ...und ja, man wird mir auch an dieser Stelle wieder erklären, dass dies nicht auf jeden Prozess bzw. jede Automatisierungsaufgabe anwendbar sei.


----------



## Thomas_v2.1 (30 Dezember 2010)

Onkel Dagobert schrieb:


> So ein Programm ist mir in diesem Jahr bei einem Kunden unter gekommen. Beim Übersetzen beisst sich die Katze in den Schwanz.


Inwiefern beisst sich die Katze in den Schwanz? Wenn ich die Bausteinschnittstelle ändere kann ich genauso wie sonst auch den Aufruf aktualisieren. Die Idee stammt auch nicht von mir, ich habe das mal in einem anderen Programm gesehen und es als garkeine schlechte Lösung angesehen, weil mir bisher auch noch keine gravierenden Nachteile aufgefallen sind.


----------



## borromeus (30 Dezember 2010)

Perfektionist schrieb:


> Na, da gibt es so Gebote, dass eine Funktionseinheit in sich abgeschlossen (gekapselt) sein sollte. Und Schnittstellen möglichst sparsam und entsprechend *offensichtlich* sein sollten. ...und ja, man wird mir auch an dieser Stelle wieder erklären, dass dies nicht auf jeden Prozess bzw. jede Automatisierungsaufgabe anwendbar sei.


 
Beispiel: 
Extruder mit 15 Heizzonen soll auf 80° heizen wenn diese im Tolaranzrahmen sind 15min warten, dann auf 160° heizen wieder den Toleranzrahmen abwarten, dann 15min warten und dann auf den Sollwert aus der Visu heizen.
Da wird wohl irgendein Baustein dies bewerkstelligen müssen, der hat aber mit dem/den Regler/n perse nichts zu tun ausser den Sollwert zu ermitteln.
Also was ist die *offensichtlichste *Schnittstelle zwischen den Bausteinen?
Ich persönlich finde hier das Beschreiben des "Zone1".SP als ziemlich *offensichtlich*.
Du nicht?


----------



## Onkel Dagobert (30 Dezember 2010)

Thomas_v2.1 schrieb:


> Inwiefern beisst sich die Katze in den Schwanz? Wenn ich die Bausteinschnittstelle ändere kann ich genauso wie sonst auch den Aufruf aktualisieren...


Ich bekam beim "Konsistenzprüfen-Alles Übersetzen" Probleme. Wenn ich mich recht entsinne waren alle diese Parameter rot und konnten nicht aktualisiert werden. Ich hätte alles manuell nachbearbeiten müssen, was sehr aufwändig geworden wäre.


----------



## Larry Laffer (30 Dezember 2010)

@Borromeus:
Das Problem ist hier NICHT das Verwenden der Daten des I-DB - das Problem ist was passiert wenn jemand die Schnittstelle des FB's ändert. Dann passen deine wunderschönen absoluten Zugriffe alle nicht mehr. Aus dem Grunde würde auch ich das als einen "faux pas" ansehen. Bei dem Versuch, sauber programmieren zu wollen, gehört der I-DB erstmal dem FB und nicht dem Rest des SPS-Programms - Stcihwort "Kapselung". Soll etwas mit den FB-Daten extern geschehen so gibt es die Schnittstelle ... auch wenn es ggf. "doppelt gemoppelt" ist.

@Thomas:
Dein Beispiel ist zwar ggf. funktionell - verbietet sich aber m.E. aus den gerade genannten Gründen genauso. Eigentlich sehe ich darin auch gar keinen Sinn.

@Ralle:
Aus meiner Sicht spricht nichts dagegen auf die Daten eines I-DB von der Visu zuzugreifen. Ggf. hat man im I-DB sogar genau dafür schon einen Koppelbereich geschaffen - ich muß allerdings gestehen, dass ich persönlich dies überwiegend nur "lesend von der Visu" mache und nur sehr selten "schreibend" und dann ist das auch irgendwo schon dokumentiert.

Gruß
Larry


----------



## Thomas_v2.1 (30 Dezember 2010)

Larry Laffer schrieb:


> @Borromeus:
> Das Problem ist hier NICHT das Verwenden der Daten des I-DB - das Problem ist was passiert wenn jemand die Schnittstelle des FB's ändert. Dann passen deine wunderschönen absoluten Zugriffe alle nicht mehr. Aus dem Grunde würde auch ich das als einen "faux pas" ansehen. Bei dem Versuch, sauber programmieren zu wollen, gehört der I-DB erstmal dem FB und nicht dem Rest des SPS-Programms - Stcihwort "Kapselung". Soll etwas mit den FB-Daten extern geschehen so gibt es die Schnittstelle ... auch wenn es ggf. "doppelt gemoppelt" ist.
> 
> @Thomas:
> Dein Beispiel ist zwar ggf. funktionell - verbietet sich aber m.E. aus den gerade genannten Gründen genauso. Eigentlich sehe ich darin auch gar keinen Sinn.



Dein Lieblingswort scheint ja "Kapselung" zu sein. Der Baustein hat eine definierte Schnittstelle, und diese Schnittstelle wird beschrieben. Wo und wieso steht in diesem Kapselungs-Gebot, dass die Schnittstelle nur am Bausteinaufruf zu beschreiben ist?


----------



## Thomas_v2.1 (30 Dezember 2010)

Onkel Dagobert schrieb:


> Ich bekam beim "Konsistenzprüfen-Alles Übersetzen" Probleme. Wenn ich mich recht entsinne waren alle diese Parameter rot und konnten nicht aktualisiert werden. Ich hätte alles manuell nachbearbeiten müssen, was sehr aufwändig geworden wäre.



Ja, beim "alles Übersetzen" kann es ein Problem geben. Aber nur wenn man dem Baustein einen Parameter entfernt. Hinzufügen funktioniert damit auf jeden Fall.


----------



## Larry Laffer (30 Dezember 2010)

Thomas_v2.1 schrieb:


> Dein Lieblingswort scheint ja "Kapselung" zu sein. Der Baustein hat eine definierte Schnittstelle, und diese Schnittstelle wird beschrieben. Wo und wieso steht in diesem Kapselungs-Gebot, dass die Schnittstelle nur am Bausteinaufruf zu beschreiben ist?



Stimmt - das ist eines meiner Lieblingsworte. Meine Programme sind grundsätzlich nicht mit nur einem "FC-all" ausgestattet. 

Du darfst von mir aus auch im Zyklsu 10 mal die Schnittstelle deines FB's neu beschreiben - aber nach meiner Denke über den FB-Aufruf und NICHT über das direkte Adressieren des I-DB's (aus dem von mir schon genannten Grund). Es geht hier nicht darum, was funktioniert und was nicht sondern um die Durchsichtigkeit - den Grund dafür hat Approx ja auch in einem seiner ersten Beiträge schon genannt ...

Gruß
Larry


----------



## Approx (30 Dezember 2010)

Larry Laffer schrieb:


> Es geht hier nicht darum, was funktioniert und was nicht sondern um die Durchsichtigkeit - den Grund dafür hat Approx ja auch in einem seiner ersten Beiträge schon genannt ...


Eben. Das der externe Zugriff auf einen IDB funzt, dessen war und bin ich mir bewusst. Mir ging es eher um die Frage nach der zeitlichen Abfolge im Zyklus. Erst IDB beschreiben, und dann FB-Aufruf, oder umgekehrt - oder ist's egal? Und ich war mir nicht sicher, was mit den unbeschalteten FB-Eingängen passiert. Ich glaube jetzt zu wissen, daß es eigentlich egal ist (sein müsste). Völlig sicher bin ich mir immer noch nicht. Naja, jedenfalls habe ich inzwischen alle verwendeten Eingangsparameter der FB's mit aussagekräftigen Operanden beschaltet. Die Sachen, die auf den Stat-Bereich zielen habe ich erstmal so gelassen. Es gab wirklich noch keine Software, bei der sich alle so beschwert haben, wie bei dieser. Kraut und Rüben sag ich nur... Die Funktion der Anlage ist halt heikel - fährt einer der Antriebe nicht, dann ist nach 5min Schluss mit lustig und Produktionsende... 
Da macht es dann sehrwohl Sinn, die Übersichtlichkeit hinsichtlich Fehlersuche zu verbessern! Alle "Extern-IDB-Verbieger" sollen machen, was sie wollen - nur nicht bei uns! 

Allen einen guten Rutsch ins 2011 und möge die Wirtschaft weiter prosperieren!


----------



## borromeus (30 Dezember 2010)

Na wenn von aussen der STAT Bereich beschrieben wird, ist es eher zum....
:sb5:


----------



## borromeus (30 Dezember 2010)

Larry Laffer schrieb:


> @Borromeus:
> Das Problem ist hier NICHT das Verwenden der Daten des I-DB - das Problem ist was passiert wenn jemand die Schnittstelle des FB's ändert. Dann passen deine wunderschönen absoluten Zugriffe alle nicht mehr. Aus dem Grunde würde auch ich das als einen "faux pas" ansehen. Bei dem Versuch, sauber programmieren zu wollen, gehört der I-DB erstmal dem FB und nicht dem Rest des SPS-Programms - Stcihwort "Kapselung". Soll etwas mit den FB-Daten extern geschehen so gibt es die Schnittstelle ... auch wenn es ggf. "doppelt gemoppelt" ist.
> Gruß
> Larry


 
Also den FB41-Regler hab ich noch nicht geändert.... in diese Verlegenheit komme ich auch nie.


----------



## Larry Laffer (30 Dezember 2010)

Approx schrieb:


> Mir ging es eher um die Frage nach der zeitlichen Abfolge im Zyklus. Erst IDB beschreiben, und dann FB-Aufruf, oder umgekehrt - oder ist's egal? Und ich war mir nicht sicher, was mit den unbeschalteten FB-Eingängen passiert. Ich glaube jetzt zu wissen, daß es eigentlich egal ist (sein müsste). Völlig sicher bin ich mir immer noch nicht.



Das war eigentlich schon gekommen.
Der unbeschaltete IN-Parameter eines FB hat erstmal den dort hinterlegten Startwert (Initialwert). Wir sprechen hier ja immer noch von einem DB.

Schreibst du im Laufe des Programms einmal einen Wert darauf, so bleibt er dort - auch wenn danach wieder unbeschaltete Aufrufe der gleichen Instanz erfolgen.

Gruß
Larry


----------



## Larry Laffer (30 Dezember 2010)

@Borromeus:
Wir sprechen hier eigentlich auch nicht von den sogenannten Standard-FB's. Mannn kann sich ja auch selber welche bauen ...


----------



## JesperMP (30 Dezember 2010)

Ich bin zusammen mit Thomas_v2.1 und Borromeus offenbar der opposition zu der Meinung von der Mehrheit das "beschreiben" von IDB Daten "Kacke" ist.

Bei Siemens ist alle Daten ja Global, wo in andere Programmiersprachen (sogar andere SPSen) gibt es bei Sub-routinen getrennt globale und locale Daten.
Ist es auch "Kacke" wenn man in diese andere Programmiersprachen oder SPSen globale Daten zugreifen ????

Ich lese und schreibe IDB Daten extern von die FBs, und habe keine Probleme damit. Auf der Gegenseite. Es erlaubt mich produktiv und strukturell zu programmieren.
Man darf die FB-Deklaration nicht ändern in Laufender betrieb ? Ja, klaro !
Man soll symbolisch programmieren ? Ja, klaro !
Kennt man nicht das "Konsistenzprüfen-Alles Übersetzen" bei STEP7 ? Dann ist man selber schuld !

Es ist ein Problem das STEP7 keine Trennung von locale/globale Daten hat, aber es bedeutet "nur" das man etwas Diziplin haben muss.
Es wird interessant zu sehen ob es bei "v11" eine Neuerung dazu wird.


----------



## borromeus (30 Dezember 2010)

Larry Laffer schrieb:


> @Borromeus:
> Wir sprechen hier eigentlich auch nicht von den sogenannten Standard-FB's. Mannn kann sich ja auch selber welche bauen ...


 
Naja, und da sind wir beim Punkt mit den IDB-Zugriffen....
man muss eben wissen "was geht" beim proggen und "was geht nimmer"..... aber es eben als schlecht darzustellen find ich halt schlecht....


----------



## Larry Laffer (30 Dezember 2010)

... da sind wir dann bei dem Punkt : "sollte man alles was man machen lann auch tun ?"

Ich sage es mal so : Wenn mir einer so etwas als Programm für unseren Betrieb unterschieben wollte dann hätte er einen sehr schweren Stand. Ich persönlich halte sehr viel von sinnvoller Strukturierung und versuche auch/sogar beim Ablauf-Programm die zusammengehörenden Dinge zusammen zu halten. Also von mir aus ... macht was ihr wollt, aber macht es nicht bei mir ... (und auch nicht mit mir ).

@Jesper:
Das "Konsistenzprüfen-Alles Übersetzen" das wieder reparieren kann (vorausgetzt man hat den Symbolvorrang aktiviert) weiß ich auch. Und hat man einmal nicht daran gedacht (oder vielleicht ein Anderer, der damit nicht rechnet) dann war es das. Sorry ... für mich ist das ein "no go".

und ...

@Borromeus:
Es liegt mir absolut fern das als "schlecht" darzustellen. Das würde ich niemals tun. Ich muß schließlich bei Rot auch nicht herausstellen, dass Rot = Rot ist ... 

Gruß
Larry


----------



## Toki0604 (30 Dezember 2010)

Ich weiß das dies keine Abstimmung ist, und ich bin sicherlich im Gegensatz zu euch allen hier ein Newcomer in der Programmierung.
Aber auf allen Siemenslehrgängen die ich besucht habe wurde uns das gelehrt was Larry sagt:
Die Möglichkeit eines Querzugriffs auf einen InstanzDB besteht programmiertechnisch grundsätzlich - JA
Doch bitte macht niemals davon Gebrauch - unschön
Aus welchen Gründen letztlich auch immer, ich halte mich daran weil es eigentlich immer auch einen anderen Weg gibt.

Gruß
Toki


----------



## borromeus (30 Dezember 2010)

Und wie ist dieser andere Weg konkret?
Einen Globaldatenbaustein verwenden?
Aber auch dem bricht die Struktur weg wenn man ihn lange genug ändert/erweitert.....

wie schön.....


----------



## Blockmove (30 Dezember 2010)

Jetzt geb ich auch mal meinen Senf dazu:
In meinen Programmen gbit es quasi 2 Arten von Bausteinen:


Sorte 1:
Bausteine für den Ablauf der Anlage (Betriebsarten, Verriegelungen, Schrittketten). Diese Bausteine sind "konservativ" programmiert. Eben so, dass der bereits zuvor angesprochene 55jährige Instandhalter und auch der Jungfacharbeiter damit klar kommt. Keine Querzugriffe, Kaum Zeiger und viele klassische Merker.
Sorte 2:
Bausteine für Typverwaltung, Prozessdaten, Berechnungen, Visualisierung. Hier kann es SCL, Zeiger, Zugriffe auf IDB oder sonstiges "Teufelswerk" geben.
Bislang bin ich damit nicht schlecht gefahren und unsere Instandhaltung hat mich auch noch nicht gelyncht 

Gruß
Dieter
​


----------



## Approx (30 Dezember 2010)

Larry Laffer schrieb:


> Schreibst du im Laufe des Programms einmal einen Wert darauf, so bleibt er dort - auch wenn danach wieder unbeschaltete Aufrufe der gleichen Instanz erfolgen.


 
Danke Larry! Genau den Satz wollte ich lesen. 

btw: Wollte hier bestimmt keine Grundsatzdiskussion über den SINN solcher Aktionen lostreten. Die gibt es eh immer wieder. Mein Chef ist auf jeden Fall meiner Meinung: Der Nächste, der so ein Schrottprogramm abliefern will, braucht gar nicht erst ins Schalthaus rein. Da muss er/sie erstmal an mir vorbei...

Es ist doch heutzutage so: Eine Firma "x" bekommt Auftrag die Anlage umzubauen, Firma x hat einen Subunternehmer "y" für die EMSR-Technik, dieser heuert einen Freelancer "z" an und so weiter... "z" kommt natürlich nicht mal aus Deutschland und ist für die Nachbesserungen dann zu teuer (Reisekosten). Die Programmleichen der Altanlage werden dringelassen, die Symboltabelle hat die Qualität einer Einkaufsliste von Oma Frieda.
Böse Mails fliegen durch den Äther, dann wird taktiert , abgewartet und die blöden Instis dürfen sich mittlerweile über 12 Monate mit einer Scheißanlage rumärgern, in deren Programm keiner mehr durchblickt.. 
Hatte nun 10 Tage zeit, dies zu ändern. Vielleicht wird nun alles gut
*AMEN!*


----------



## Larry Laffer (30 Dezember 2010)

borromeus schrieb:


> Und wie ist dieser andere Weg konkret?
> Einen Globaldatenbaustein verwenden?
> Aber auch dem bricht die Struktur weg wenn man ihn lange genug ändert/erweitert.....



Mach mal ein konkretes Beispiel ... nicht zu ausladend aber doch noch so, dass man sich daran etwas überlegen könnte ... vielleicht gibt es ja doch etwas Schöneres wie die von dir so favourisierten Quer-Zugriffe. Vielleicht muss ich aber dann auch wirklich passen ... 

@Approx:
Eine Grundsatz-Diskussion war doch schon lange mal wieder dran ...


----------



## Toki0604 (30 Dezember 2010)

> Mach mal ein konkretes Beispiel ... nicht zu ausladend aber doch noch so, dass man sich daran etwas überlegen könnte ... vielleicht gibt es ja doch etwas Schöneres wie die von dir so favourisierten Quer-Zugriffe. Vielleicht muss ich aber dann auch wirklich passen ...
> 
> @Approx:
> Eine Grundsatz-Diskussion war doch schon lange mal wieder dran ... :wink:


 
Ich schließe mich dem an .
Vielleicht aber wäre alles weitere dann ein Fall für das Thema "Programmierstrategien".
Gruß
Toki


----------



## borromeus (30 Dezember 2010)

Larry Laffer schrieb:


> Mach mal ein konkretes Beispiel ... nicht zu ausladend aber doch noch so, dass man sich daran etwas überlegen könnte ... vielleicht gibt es ja doch etwas Schöneres wie die von dir so favourisierten Quer-Zugriffe. Vielleicht muss ich aber dann auch wirklich passen ...
> 
> @Approx:
> Eine Grundsatz-Diskussion war doch schon lange mal wieder dran ...


 
Ich habe es schon geschrieben, es gibt Dinge wo man das anwenden kann, zB bei StandardFB's, die sich nie ändern.
Einen Visuzugriff zB würde ich nicht auf die Instanz legen, weil es, ausser mir bekannt beim PCS7, zu einem Deasaster kommen würde wenn sich die Instanz ändert.

Das Beispiel:
siehe oben...die Heizung....
Lege ich die 15 Sollwerte brav in den GlobalDB, säuberlich hintereinander, und lasse dann noch 3 DD Reserve, kann es mir trotzdem passieren, dass 4 Heizungen dazukommen... da steht dann am Ende des DB's der 19te Sollwert.
Das finde ich auch nicht schön.

Ich denke, es ist eben eine Erfahrungssache "was geht, und was ned"....

Viel wichtiger ist mir eigentlich, dass einer seine Gedanken auch textlich wiedergibt..... der erste Fehler bin ich immer selber, wenn ich im Programmierfluss die für mich naheliegenden Gedanken hinein-awelle (a-we-elle ).... 6 Monate später frage ich mich welcher Koffer das programmiert hat..... daher habe ich es mir angewöhnt scheinbar einfache Dinge auch zu dokumentieren.....
Jeder IH freut sich darüber.


----------



## Ralle (30 Dezember 2010)

Larry Laffer schrieb:


> @Ralle:
> Aus meiner Sicht spricht nichts dagegen auf die Daten eines I-DB von der Visu zuzugreifen. Ggf. hat man im I-DB sogar genau dafür schon einen Koppelbereich geschaffen - ich muß allerdings gestehen, dass ich persönlich dies überwiegend nur "lesend von der Visu" mache und nur sehr selten "schreibend" und dann ist das auch irgendwo schon dokumentiert.
> 
> Gruß
> Larry



Lesen ist ok, das mache ich auch bei bestimmten Sachen. Auf meine HP ist eine Baustein, Um die Daten aus einem PNOZ-Multi auszulesen. Da kann man auch in den IDB, um wirklich alles an Daten sehen zu können, aber heir wäre ein Koppelbereich auch ziemlich sinnlos.


----------



## Larry Laffer (31 Dezember 2010)

@Ralle:
das wäre dann z.B. so ein Beispiel - so ein ähnliches Ding habe ich auch. Eine andere Sache wäre z.B. eine Kurven-Aufzeichnung und -Auswertung. Hier werden alle Info's vom FB generiert und im I-DB hinterlegt - und bis auf die Ergebnisse IO oder NIO (und das sind dann OUT's) braucht das SPS-Prohgramm davon gar nichts sondern nur die Visu um es anzuzeigen.

@Borromeus:
Wenn du die Visu auf die Instanz legst, so ist diese symbolisch mit derselben verbunden. Selbst wenn du den I-DB komplett änderst würde ein Neu-Generieren des Visu-Projektes alle Variablen wieder korrekt anschließen (außer es haben sich deren Namen geändert - das schließe ich aber mal aus und wenn da müßte man da eben "mal Hand anlegen").

@Borromeus:
Für den von dir geschilderten strukturierten Aufbau des "regulären DB's" stimmt das - und auch wieder nicht. Wenn du unbedingt irgendwo ein paar DBD's (oder so) dazwischen schieben möchtest dann ist das auch kein Thema. Wichtig wäre hier, dass du alle DB-Variablen sysmbolisch im Programm ansprechen kannst. Nun "verschmickelst" du einfach den DB (sprich du erweiterst ihn), stellst in deinem Projekt den Operanden-Vorrang auf "symbolisch" und generierst es neu (das war der Vorschlag von Jesper). Nun werden in deinem Projekt alle Adressen angepasst. Nun einfach die geänderten Bausteine in die SPS spielen.

Gruß
Larry


----------



## borromeus (31 Dezember 2010)

Larry Laffer schrieb:


> Wenn du die Visu auf die Instanz legst, so ist diese symbolisch mit derselben verbunden. Selbst wenn du den I-DB komplett änderst würde ein Neu-Generieren des Visu-Projektes alle Variablen wieder korrekt anschließen (außer es haben sich deren Namen geändert - das schließe ich aber mal aus und wenn da müßte man da eben "mal Hand anlegen").
> 
> Gruß
> Larry


:shock:

Wie geht das bei Intouch?


----------



## Larry Laffer (31 Dezember 2010)

borromeus schrieb:


> :shock:
> 
> Wie geht das bei Intouch?


kann ich dir nicht sagen, da ich seit über 10 Jahren nicht mehr damit gearbeitet habe. Da Intouch aber nicht selber mit der SPS kommuniziert sondern sich da eines IO-Servers (so hies das früher mal) oder eines OPC's bedient könnte ich mir vorstellen, dass es dort auch eine Flex-kompatible Symbol-Tabelle gibt, die man ggf. neu zuordnen kann. Falls ich mich da täuschen sollte dann würde ich sagen, dass die "wunderbare Wunderware" technologisch ein bißchen hinter den Möglichkeiten der Zeit zurück geblieben ist.

Gruß
Larry


----------



## Thomas_v2.1 (31 Dezember 2010)

@Larry
Du hast eine seltsame Logik. Wenn einer vom Programm aus auf den IDB zugreift wird er vom Hof gejagt, wenn du das von der Visu macht weil es doch wohl irgendwie praktisch erscheint ist sogar das Schreiben erlaubt ("Es ist dann schon irgendwo dokumentiert").
Ich lach mich echt weg... trotzdem noch einen guten Rutsch.


----------



## Larry Laffer (31 Dezember 2010)

@Thomas:
Schade, dass du meine Beiträge entweder nicht richtig liest oder ggf. nur das daraus liest, was du lesen möchtest. Aber wie auch immer. Der signifikante Unterschied ist der : Die Visu (hier z.B. WinCC-Flexibel) stellt nicht vordergründig einen absoluten Zugriff her sondern sie adressiert die Variablen symbolisch. Ändern sich also die Adresse einer dieser "symbolisch adressierten" Variablen so wird durch ein "neu generieren" des Visu-Projektes die Adresse korrekt wider hergestellt - ohne weiteres Zutun.
Über diese Funktion verfügt natürlich auch das SPS-Programm selber (vorausgesetzt die Spielregeln wurden eingehalten). Jesper hat das ja schon erwähnt.  Der Unterschied ist nur : das "Neu übersetzen" des SPS-Programms funktioniert nur solange wie die betreffenden Bausteine nicht manuell schon angefasst wurden. Aus dem Grunde halte ich das hier für sehr fragwürdig, denn hat man den baustein schon mal angefasst bevor neu übersetzt wurde so kann dabei dann etwas "richtig Lustiges" entstehen.

Ich habe in meinem Programm FB's deren vorrangige Funktion es ist für die Visu Daten aufzubereiten. Die heissen dann auch so. Sollten diese dann auch mit dem restlichen SPS-Programm noch etwas zu schaffen haben so geschieht dies über die Schnittstelle. Manche dieser FB's werden in meinen Programm mit gleicher oder unterschiedlicher Instanz (immer wie benötigt) mehrfach im Programm aufgerufen. Was die im Einzelnen machen ist mir jetzt zu umfangreich das darzustellen. Jedenfalls - auf diese Bausteine (und auf keine Anderen) greift die Visu dann nicht nur Lesend sondern auch Schreibend zu. Etwas Vergleichbares mache ich übrigens auch z.B. mit FU's oder Servo-Achsen. Der FB arbeitet mit der Perepherie und führt ggf. auch eigene Funktionen aus und stellt nach Aussen "nur" die Kontroll-Schnittstelle zur Verfügung (und ggf. auch die Parametrierung).

Aber wie ich schon sagte, wir alle leben in einem freien Land und jeder darf sich SEINE SPS-Programme so vermurksen wie er es möchte. Es ist nur so, dass ich manchmal (wenn ich den Eindruck habe, dass es wen interessiert oder ich jemanden damit meine helfen zu können) zu manchen Macharten auch mal meine Meinung kund tue. Das die nicht immer bei Allen auf Gegenliebe stößt weiß ich auch - aber ich nehme das mit dem "freien Land" halt auch manchmal für mich in Anspruch ... 

Gruß
Larry


----------



## logo-elan (19 Mai 2018)

Ich muss diesen alten Schinken hier mal wieder ausgraben und euch nach eurer aktuellen Meinung zu dem Thema fragen. 
In Zeiten von Tia V15 und dem "aussterben" der absoluten Adressierung bin ich nämlich mittlerweile nicht mehr wirklich der Meinung, Speicherplatz verschwenden zu müssen, um IDB-Daten nicht direkt zu schreiben. Querverweise werden im Portal sauber angezeigt und beim Übersetzen werden alle zugehörigen Aufrufe automatisch aktualisiert, sobald sich die Schnittstelle eines FB's ändert.
Selbst eine HMI (die auch symbolisch adressiert) spricht ohne Software-übersetzen und aufspielen nach ändern der FB-Schnittstelle den richtigen Adressbereich an.

Ich persönlich nutze den Stat-bereich der IDB's mittlerweile gerne dazu, um alle nötigen Ein-und Ausgangsvariablen kompakt abzulegen und keine Umwege mehr über die In/Out Schnittstellen machen zu müssen.

Was denkt ihr?


----------



## maxder2te (22 Mai 2018)

logo-elan schrieb:


> Ich muss diesen alten Schinken hier mal wieder ausgraben und euch nach eurer aktuellen Meinung zu dem Thema fragen.
> In Zeiten von Tia V15 und dem "aussterben" der absoluten Adressierung bin ich nämlich mittlerweile nicht mehr wirklich der Meinung, Speicherplatz verschwenden zu müssen, um IDB-Daten nicht direkt zu schreiben. Querverweise werden im Portal sauber angezeigt und beim Übersetzen werden alle zugehörigen Aufrufe automatisch aktualisiert, sobald sich die Schnittstelle eines FB's ändert.
> Selbst eine HMI (die auch symbolisch adressiert) spricht ohne Software-übersetzen und aufspielen nach ändern der FB-Schnittstelle den richtigen Adressbereich an.
> 
> ...


Wenn du im STAT-Bereich einen sauberen Bereich definierst für IN bzw. OUT-Daten, so dass eindeutig erkennbar ist, was rein und was raus soll, dann spricht nicht viel dagegen. Allerdings hat man dann keinen Speicher- und Laufzeitvorteil gegenüber echten IN/OUT-Variablen.

Wenn man kreuz und quer in die STAT-Variablen schreibt oder daraus liest, wirds halt schnell unübersichtlich und ich frage mich, ob das Programm jemand anders als Du auch lesen kann.

Das Stichwort "Speicher verschwenden" sollte in S7-1500 Zeiten eigentlich auch keines mehr sein, über Speicherverbrauch mache ich mir nur noch bei Standardpaketen Gedanken, die hundertfach verwendet werden - und das i.d.R. nicht von mir sondern von Kollegen - und jetzt ist wieder der Punkt erreicht wo Schnittstellen klar definiert sein sollten,

Summa summarum: Es gilt die Faustregel "Auf Instanzdaten wird nicht zugegriffen. Punkt."


----------

