Ja, ich greife zu. Ich greife in einer Instanz mit der HMI so ungeniert zu, wie in einer SPS im Merkerbereich.
Das überrascht mich dann doch gehörig, wo Du doch so oft von Kapselung schreibst und Querzugriffe auch ablehnst.
Fast möchte ich Dir vorschlagen, unsere Nicknames zu tauschen. Mir deucht, Deiner passt besser zu mir
Schließt man das Kabel vom Start/Stop-Taster samt Leuchtmelder direkt am Hauptschütz des Antriebs an oder benutzt
man Hilfskontakte und setzt im Schaltschrank eine extra Klemmleiste?
Warum soll man nicht in der Elektrik bewährte Prinzipien auch für die Programmierung anwenden, auch wenn man nicht
weiß, warum etwas heute so-und-so gemacht wird?
Ich war jetzt auf der Suche nach der Fraktion, die den Zugriff der HMI auf Instanzen verachtenswert findet.
Ich finde Zugriffe der HMI auf Instanz-DB als absolutes No-Go, und zwar aus praktischen Erfahrungen.
Ich hatte in meinem Programmiererleben auch mal die Phase, wo ich HMI-Zugriffe auf IDB in Ordnung fand (ist doch
so quick und easy), doch spätestens bei nachträglichen Änderungen an diesen Programmen wurde ich dafür mit teils
erheblicher Mehrarbeit bestraft.
Gründe für meine Meinung:
* die Problematik der Initialisierung von IDB bei deren Neu-Generierung wurde schon von Paule genannt
* manchmal kann das HMI-Projekt nicht geändert werden oder die Änderung ist sehr aufwendig
* ich möchte bei Programmänderungen nur eine (zusammenhängende) Schnittstelle zur HMI beachten müssen
* mein Steuerungsprogramm soll Vorrang vor Eingriffen der HMI haben
* keine Eingaben/Bedienungen der HMI werden ungeprüft oder unverknüpft im Steurungsprogramm verarbeitet
* die HMI und die HMI-Animationen sind leichter testbar, wenn sie nicht auf die original-Variablen zugreifen
Es kommt öfter vor als gedacht, daß Hersteller einer Anlage wegen schlechtem Projektmanagement nicht mehr wissen,
welche HMI-Projektversion aktuell in der Anlage ist oder das aktuelle HMI-Projekt garnicht mehr besitzen. Und noch
öfter, daß sie für ein paar simple Adress-Anpassungen exorbitante Preise verlangen.
In diesen Fällen dürfen also Programmänderungen auf keinen Fall Einflüsse auf die HMI haben.
Wenn ich dann IDB nicht ändern darf, weil die HMI wahrscheinlich direkt darauf zugreift, dann möchte ich regelmäßig
jemanden würgen ...
Doch auch wenn das HMI-Projekt vorhanden ist, kann eine notwendige Änderung an IDB (besonders bei Multi-Instanzen)
erhebliche Arbeit am HMI-Projekt nach sich ziehen. Oft ist das HMI-Projekt nicht im Steuerungsprojekt integriert.
Dann müssen alle nötigen Adressänderungen per Hand ausgeführt werden. Und nicht jede HMI-Software ist so einfach
aufgebaut wie ProTool.
Immer ist aber zumindest eine Neu-Generierung des HMI-Projektes nötig und es muß (meist im laufenden Betrieb) auf
alle betroffenen Panele und Visualisierungen aufgespielt werden. Das können auch mal 10 OP7 sein, wo man mit dem
Notebook zu jedem einzelnen OP hinlaufen muß, um das Projekt aufzuspielen. Dazu kommt der Organisationsaufwand,
weil die noch nicht upgedateten Panele auf keinen Fall benutzt werden dürfen oder die Panele müssen gar vorab alle
ausgeschaltet werden.
Diese viele Arbeit ist nicht nötig, wenn die HMI ausschließlich über wenige Schnittstellen-DB auf die Steuerung
zugreift und niemals über IDB. Ich betrachte die HMI-Schnittstellen-DB als Rangier-Klemmleiste zur HMI.
Bei mir erhält die HMI fast nie Zugriff auf die original-Steuerungsvariablen, sondern regelmäßig nur auf Kopien
oder Zwischenvariablen in den Schnittstellen-DB. So ist es unerheblich, wenn die HMI durch Projektierungsfehler
oder Compilierfehler auf diese Variablen schreibt. In den meisten HMI-ES die ich kenne, kann man Prozessvariablen
nicht als read-only deklarieren. Nur in Wonderware Intouch kann man ein entsprechendes Häkchen setzen, doch auch
da wird dieses Feature sogut wie nie von anderen Programmierern genutzt, weil das zusätzliche Arbeit macht.
(Hier muß ich allerdings erwähnen, daß man bei Simatic-CPU alle Variablen generell nicht vor Schreibzugriffen von
außen schützen kann. Einziger sicherer Schutz: nicht vernetzen!)
Eingabewerte von der HMI lasse ich nicht ungeprüft auf Steuerungsvariablen schreiben. Ich möchte nicht, daß meine
CPU in Stop geht oder das Steuerungsprogramm ins schleudern gerät, nur weil die HMI oder ein anderer vernetzter
Teilnehmer einen ungeeigneten Wert oder im ungünstigen Moment in eine Variable schreibt.
Auch Rezepturen lasse ich nicht direkt in die Zielvariablen schreiben, sondern immer nur in einen Datensatz-Puffer.
Bei mir bestimmt das Steuerungsprogramm, ob und wann es die neuen Rezepturwerte übernimmt.
Tastenbits von der HMI werden immer wie normale Hardware-Taster im Programm verknüpft und zusätzlich zu Beginn des
ersten OB1-Zyklus und am Ende des OB1 gelöscht, weil nicht sicher ist, daß auch der Tasten-Release-Code von der HMI
in der Steuerung ankommt.
Ausnahmen von diesen Prinzipien kommen vor, haben dann spezielle Gründe, bestätigen aber die Regel.
Weil ich nicht bei jedem Projekt von vornherein sagen kann, ob die Einhaltung meiner Prinzipien nun für dieses
spezielle Projekt essentiell ist und was später noch draus wird, halte ich es eben immer so.
Ich sehe diese Prinzipien als einen wesentlichen Baustein dafür, daß die von mir programmierten Anlagen in aller
Regel jahrelang ohne Steuerungsprobleme und immer berechenbar funktionieren.
Ach ja:
Die HMI und die HMI-Animationen sind viel leichter testbar, wenn sie nicht auf die original-Variablen zugreifen,
sondern auf Variablen-Kopien im Schnittstellen-DB, besonders im laufenden Betrieb.
Die Variablen-Kopie im Schnittstellen-DB läßt sich ohne Auswirkungen auf das Steuerungsprogramm gut manipulieren.
Gruß
Harald
