Problem: Externer Zugriff auf IDB's

[Approx]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

@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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@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]

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]

: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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@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]

@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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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?

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."