Problem: Externer Zugriff auf IDB's

Zuviel Werbung?
-> Hier kostenlos registrieren
..Damit der FB dann aber nicht nackt ohne Beschaltung dasteht, kann man auch die Parameter mit dem eigenen Instanz-DB beschalten, also so:
Code:
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.
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.
 
... 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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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?
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@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
 
@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?
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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! :ROFLMAO:

Allen einen guten Rutsch ins 2011 und möge die Wirtschaft weiter prosperieren!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@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.
 
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
 
@Borromeus:
Wir sprechen hier eigentlich auch nicht von den sogenannten Standard-FB's. Mannn kann sich ja auch selber welche bauen ... ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
@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....
:)
 
... 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 :ROFLMAO:).

@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 ... :rolleyes:

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.....
 
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

 
Zuletzt bearbeitet:
Zurück
Oben