Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 22

Thema: Seiteneffekte bei externem Zugriff auf Instanzdatenbaustein? (SCL)

  1. #1
    Registriert seit
    29.09.2011
    Ort
    Kronshagen
    Beiträge
    8
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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
    Zitieren Zitieren Seiteneffekte bei externem Zugriff auf Instanzdatenbaustein? (SCL)  

  2. #2
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.794
    Danke
    398
    Erhielt 2.417 Danke für 2.013 Beiträge

    Standard

    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

  3. Folgender Benutzer sagt Danke zu Larry Laffer für den nützlichen Beitrag:

    Aventinus (27.06.2012)

  4. #3
    Horst-Kevin ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    29.09.2011
    Ort
    Kronshagen
    Beiträge
    8
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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

  5. #4
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard

    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'
    Jesper M. Pedersen

  6. #5
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.263
    Danke
    537
    Erhielt 2.708 Danke für 1.957 Beiträge

    Standard

    Zitat Zitat von JesperMP Beitrag anzeigen

    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.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  7. #6
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    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.
    Jesper M. Pedersen

  8. #7
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.263
    Danke
    537
    Erhielt 2.708 Danke für 1.957 Beiträge

    Standard

    Zitat Zitat von JesperMP Beitrag anzeigen
    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ß...
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  9. #8
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    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'.

    Zitat Zitat von Ralle Beitrag anzeigen
    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.
    Jesper M. Pedersen

  10. #9
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.263
    Danke
    537
    Erhielt 2.708 Danke für 1.957 Beiträge

    Standard

    Zitat Zitat von JesperMP Beitrag anzeigen
    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.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  11. #10
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Ralle
    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.
    Jesper M. Pedersen

Ähnliche Themen

  1. Indirekter zugriff auf DB's (SCL)
    Von zloyduh im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 03.05.2012, 09:45
  2. Antworten: 1
    Letzter Beitrag: 23.01.2012, 17:06
  3. Zugriff auf WinPLC-Engine mit externem Programm
    Von Murdock73 im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 20.02.2009, 15:56
  4. Indizierter Zugriff auf Datenbaustein im SCL
    Von tarzipan7 im Forum Simatic
    Antworten: 12
    Letzter Beitrag: 05.02.2008, 15:37
  5. SCL - Indirekter Zugriff auf DB/AR1,2
    Von Floh im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 07.06.2006, 10:32

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •