Vermeiden von Globaldaten

miasma

Level-2
Beiträge
368
Reaktionspunkte
114
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich beschäftige mich gerade konzeptionell mit der Umstellung meiner eigenen Programmierweise.
Ziel ist es Modulare Bausteine zu entwickeln die einfach wiederverwendet werden können.Ihre Daten sollen über eine Strukturschnittstelle (ein und ausgangsseitig) an die HMI, an ein Faceplate übergeben bzw. gelesen werden.

Mir schwebt wirklich vor vollkommen auf Globale Daten zu verzichten um möglichst keine Probleme beim wiederverwenden zu bekommen.

Hintergrund ist folgender. Ich möchte gerne das die Bausteine im Aufruf eine schlanke Schnittstelle haben. Im Grunde genommen sollen nur noch Daten aus der Peripherie in der Schnittstelle adressiert werden.Gerade auf der IN Seite der Schnittstelle werden meiner Meinung nach Bausteine oftmals mit überflüssigen Daten versorgt die genauso gut intern erzeugt werden können oder als Struktur anstelle von Einzeldaten übergeben werden können.

Intern erzeugt werden können:
  • Taktbits
  • Logisch 0 & 1
  • Timer Nummern
  • etc.
Strukturen sollen Einzeldaten ersetzen wie:
  • Eingangsvariablen die eine Skalierung beschreiben. HiLim, LoLim, ZA++, A+, A-, ZA--, Ersatzwert etc. Da man die Struktur sowieso nicht beobachten kann sollen Daten dieser Art aus der Visu direkt in einen Struktur in den STAT Bereich eines FB's übergeben werden.
  • Ausgangsvariablen wie z.b Rohwert, Skalierter Wert und Normsignal.
  • etc.
Sicherlich ist das hier nur eine sehr grobe Beschreibung meiner Vorstellung. Aber mich würde es interessieren wie IHR einen solchen Ansatz bewertet.

Gibt es hier Leute die so arbeiten und von Vorteilen und Nachteilen berichten können ? Oder Leute die einen solchen Ansatz im allgemeinen begründet mit Nachteilen ablehnen ?
 
Ich persönlich bin kein Freund des vollkommenen Verzichts auf Globaldaten.
Bei der Fehlersuche musst du dich durch die ganze Aufrufhierachie hangeln. Querverweis bzw. "Gehe zu Verwendungstelle" funktionieren nicht.
Ich verwende Stationsbezogene Global-DB mit Strukturen.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber beobachten mit Aufrufpfad und Ctrl+Shift+F und Ctrl+Shift+B (lokale Verwendungsstelle) funktionieren doch um zur nächsten bzw. vorherigen Verwendungsstelle zu springen.

Ein Querverweis ist doch auch gar nicht mehr möglich bzw. nötig weil der Datenpunkt nur noch lokal in der Instanz verwendet wird.
Ein Querverweis funktioniert doch im Grunde genommen nur bei Globaldaten.
 
Du widersprichst dir.

Du sagst ein Datenpunkt wird nur Lokal genutzt, willst aber aus der Visu, und von sonst wo noch von Extern drauf "rumpfuschen"...

Ich habe alles in gekapselten FBs, und schmeisse da eine Struktur dran, die dann in Global-DBs liegt!

Grüße

Marcel
 
Ja lokal auf der Steuerung im Baustein der den Datenpunkt bearbeitet. Die Visu beschreibt nur die Variable der Instanzdaten. Weitere Zugriffe soll und wird es nicht geben. Das ist kein Wiederspruch oder ich verstehe nicht was Du meinst. Der Zugriff der Visu auf einen Datenpunkt stellt meiner Meinung nach nur ein beschreiben einer Variable da und somit bleibt der Datenpunkt lokal.

Genau das will ich vermeiden. Eine FB aufrufen und dann noch einen DB erzeugen der den FB versorgt.
Dann habe ich einen FB mit Instanzdatenbaustein und Datenbaustein.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja du siehst aber nicht das die Visu in deinem Lokaldaten rumpfuscht!

Ich habe z.B. einen Baustein der mir Daten zur Visu hoch schießt, der heißt dann auch VISU_KOPPEL_DB!

Und das Argument mit ein FB und einen GDB ist auch käse, ich habe z.B. einen GDB mit 20 Zylinder-UDTs, auf den ich sauber aus dem Programm und aus der Visu zugreifen kann, ohne auch nur eine Lokale Variable genutzt zu haben!

Grüße

Marcel
 
Das verstehe ich nicht wieso soll ich einen extra DB zur Visu anlegen wenn ich im Instanzdatenbaustein unter STAT eine Struktur zum Senden an die Visu und eine zum empfangen von der Visu anlegen kann.
Ich müsste diesen DB jedes mal wieder neu erzeugen wenn ich eine neue Anlage mit anderer Konfiguration Programmieren will.

Ist es denn wirklich so gängige Praxis,das Daten die nur an einer einzigen Stelle in einem Programm genutzt werden Global zur Verfügung gestellt werden in einem DB oder gar noch schlimmer in einem Merker ?
 
Also ich versuch es mal etwas detailierter zu machen....


Ich habe einen GDB für Zylinder.

Dort ist dann 30mal die Zylinderstruktur drin. Vereinfacht ist das mal:

IN
Auto_in_GS
Auto_in_AS
Hand_in_GS
Hand_in_AS
OUT
POS_IN_GS
POS_IN_AS

Das ganze hab ich da drin wie gesagt 30 mal, die nennen wir dann mal Zylinder1, Zylinder2, ZylinderN...

Wenn ich im Handbetrieb Zylinder 1 verfahren muss schreibe ich also GLOBAL_DB.Zylinder1.IN.Hand_nach_GS
und fahre Zylinder 1 damit per Hand in GS. Automatisch ist das natürlich gleich.

An meinen Zylinder FB welchem ich keinen IDB gebe, sondern in dem STAT bereich des ANALGE_ALLGEMEIN FB aufrufe, übergebe ich GLOBAL_DB.Zylinder1, und binde an den Endschalter, Ventile, u.ä. direkt an.

Die Visu greift auch auf die Struktur im Globalen DB zu!

Somit habe ich für meine Aufgaben:

einen Aufruf FB mit den Instanzen der Zylinder im STAT bereich
einen GLOBAL DB mit den Schnittstellendaten
und beliebige Zugriffe über den Global DB

Ich spare mir auf diese Art einen riesen Arsch voll IDBs, habe eine immer identische Aufrufstruktur, die sich nur in dem Zylindernamen unterscheidet, habe volle "Gehe zu verwendungsgelle" Funktionalität und kann sogar noch den Vorteil nutzen das ich bei dem Zylinder FB die IN Variablen "ignorieren" bzw. ENABLEn kann, und somit auch einen Zylinder ohne großen Aufwand deaktivieren könnte.

Das hat sich für mich und meine Kollegen als eine gute und gängige Praxis bewährt!

Grüße

Marcel


Edit: Ach ja der Globale DB sollte so ausgelegt sein, dass man immer ReserveStrukturen hat... aber auch das nachträgliche Anfügen ist kein Problem...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Matze

Ich mache es ebenfalls in dieser Art und Weise.
Dazu noch stationsbezogene DBs mit Betriebsarten und Typdaten und Gut is.

Mir ist Querverweis und volle Gehezu-Funktionalität auch extrem wichtig.

Gruß
Dieter
 
@Matze
Wozu nutzt man dann überhaupt einen FB wenn man die Daten aus einem externen Datenbaustein liest und schreibt ?

@Blockmove

Wozu sollte ein Querverweis bei lokaldaten dienen ?
 
Wozu sollte ein Querverweis bei lokaldaten dienen ?
Nur "gehe zur vorherigen Verwendung" + "gehe zur nächsten Verwendung" ist einfach zu wenig. Ich brauche eine Liste aller Verwendungsstellen inklusive Kennzeichnung Schreibzugriff/Lesezugriff.


Die Nutzung von Strukturen als Übergabeparameter kann ich bei Siemens S7 nicht empfehlen, weil:
Das erzeugt unheimlich aufgeblähten Code um die Variablenadressen zur Laufzeit zu berechnen (je Variablen-Zugriff ca. 40 Byte extra).
Außerdem kann der aufgerufene Baustein auch INPUT(!)-Strukturen nach Belieben beschreiben und das ist nicht in den Referenzdaten zu sehen. Wie überhaupt jeder Strukturvariablen-Zugriff nicht zu sehen ist. Außerdem unterstützen die Referenzdaten keine Strukturen, d.h. Variablen einer Struktur lassen sich in den Referenzdaten nicht zusammenfassen.

Und imho sollte jeder PLC-Programmierer davon ausgehen, daß eines Tages ein anderer Programmierer den Code zügig verstehen können muß. Das wird bei "schlanken Schnittstellen" verdammt schwer ...

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich nutze einen FB weil ich nicht meine ganzen Internen Zustände in den GlobalDB packen will.
Ich könnte das so machen, keine Frage! Aber ich habe lieber eine Schlanke Schnittstelle im Globalen DB!

Zu den Querverweisen bei Lokaldaten:

Sie heißen zwar bei dir Lokaldaten, aber wenn du von jeder stelle darauf schreiben willst vergewaltigst du sie als Globaldaten!

Grüße

Marcel
 
Wenn man ein Programm von einem Fremden in Hände bekommt, dort Fehler suchen oder Änderungen machen muss, dann erübrigt sich doch die Frage des TE.

Mit den Zugriffen von irgendwoher auf IDB und dann dort Fehler zu suchen, wenn es einmal knallt?
Ein IDB gehört dem dazugehörigen FB und sonst niemand.
Wer seine Schnittstelle in einem Globalen DB zur HMI sauber aufbaut, der hat viel weniger Arbeit und Ärger, wenn ein neues Projekt ansteht.

Daher versteh ich die Frage nicht wirklich.
Ich programmiere nicht für mich, sondern für den Kunden und die Nachfolger, die das Programm am Leben erhalten.


bike
 
Mit den Zugriffen von irgendwoher auf IDB und dann dort Fehler zu suchen, wenn es einmal knallt?
Ein IDB gehört dem dazugehörigen FB und sonst niemand.
Wer seine Schnittstelle in einem Globalen DB zur HMI sauber aufbaut, der hat viel weniger Arbeit und Ärger, wenn ein neues Projekt ansteht.
Woran kann man denn erkennen dass eine Visualisierung oder eine andere Station auf einen globalen DB schreibt? Nur an dem Namen? Was ist wenn ich im den statischen Daten des FB eine Struktur HMI anlege und die Visu nur auf diese Daten zugreifen darf, gilt das dann auch als OK?

Wenn man es wirklich sauber machen wollte müsste man einen Dummy FC mit meinetwegen Namen "HMI-Schnittstelle" schreiben, an dessen In-Out Parameter alle Werte die von der Visu geschrieben werden parametriert werden. Nur dann finde ich Zugriffe auch in der Querverweisliste wieder.
 
Klar kann man das machen, aber ob es dadurch sauberer ist bezweifel ich mal ;)

Ich finde einen Global-DB eindeutig! Wie stellst du dir das mit dem FC vor? Direkt in den IN-Bereich schreiben? Nen Global-DB an den IN-Bereich anknüpfen? Damit drehen wir uns wieder im Kreis.

Irgendwie hat meiner Meinung nach alles außer nem GDB kein Hand und Fuß!

Grüße

Marcel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Klar kann man das machen, aber ob es dadurch sauberer ist bezweifel ich mal ;)

Ich finde einen Global-DB eindeutig! Wie stellst du dir das mit dem FC vor? Direkt in den IN-Bereich schreiben? Nen Global-DB an den IN-Bereich anknüpfen? Damit drehen wir uns wieder im Kreis.
Nein, einfach nur durch einen FC durchleiten, damit man es in der Querverweisliste wiederfindet.
Irgendwie hat meiner Meinung nach alles außer nem GDB kein Hand und Fuß!
Nur wer hat denn festgelegt dass von außen auf einem bestimmten global-DB geschrieben werden kann?
Wenn man in der SPS den Zugriff von außen auf einen einzigen DB beschränken könnte, würde ich das noch als schlüssig hinnehmen. Da es das aber nicht gibt, kann ich im Programm auch bei global DBs nicht nachvollziehen auf welche DBs die Visualisierung denn jetzt schreibt.

Ich bin jetzt nicht generell nur für das eine oder andere (ich habe beides gemacht und es gibt bei beiden Wegen Vor- und Nachteile), aber die Argumentationskette von den pro Global-DB Leuten ist meiner Meinung nach sehr dünn.
 
Ich mache es mir persönlich immer recht leicht!

Ich habe folgende GDBs:

VISU_ALLGEMEIN -> Hier sind ein Paar Bool, Byte, INT, REAL, ... die die Visu allgmein austauscht
ZYLINDER -> Hier ist alles was mit den Zylindern zu tun hat, mit nem bereich für die Visu
KOMMNUNIKATION_MASCHINE1 -> Hier landen Daten per S7-Verbindung von Maschine1
...

Somit ist für mich beim Überblicken des Programms schnell ersichtlich was wo passiert.
Außerdem kann ich hier mit Reserven arbeiten, und z.B. die Vorbereitung für 20 Zylinder schaffen,
die dann halt im Programm "totlaufen" und nicht aufgerufen werden. Wenn ich direkt auf den IDB gehe
dann MUSS ich diesen im Programm haben, also auch aufrufen!

Das ist mein Vorgehen, ich möchte es keinen Aufzwingen!

Grüße

Marcel
 
Da es das aber nicht gibt, kann ich im Programm auch bei global DBs nicht nachvollziehen auf welche DBs die Visualisierung denn jetzt schreibt.

Vielleicht versteh ich jetzt etwas falsch.
Meine HMI schreibt und liest aus einem eigenen Global DB.
Wenn etwas nicht passt, dann kann erkannt werden, ob der Fehler aus dem GlobalDB kommt oder nicht.
Wenn ein IDB von anderen Funktionen umgeschrieben wird, dann ist das schwer zu finden.
Es kann einen blöden Effekt geben, wenn der FB einen Wert ändert, dann ändert die HMI diesen ebenso in selben Zyklus :rolleyes:

Jeder so wie er oder sie will. Meine Erfahrung zeigt, dass diese Art nicht ganz so falsch sein kann.
Bisher kamen noch keine Reklamationen von anderen.


bike
 
Zurück
Oben