Hallo Harald,
heute mittag hab ich mich zunächst damit auseinandergesetzt, wie ich dazu stehe, wenn man etwas soundso tun solle, weil man es schon immer soundso gemacht habe. Wegen der angeführten Beispiele aus der alltäglichen Welt der Autofahrer fiel mir eine spontane Antwort darauf leicht. Ich ergänze nun noch ein paar meiner Gedanken zu den fachbezogenen Dingen - natürlich insbesondere dort, wo sich bei mir Widerspruchsbedürfnis entwickelt.
Spätestens, wenn man keine Lizenz für die spezielle HMI-Generiersoftware hat oder das aktuelle HMI-Quellprojekt einfach nicht vorhanden ist, dann ist die HMI eine Blackbox und hat sich gefälligst an dokumentierte Schnittstellen zum Steuerungsprogramm zu halten.
Hmmm, kann sein, dass ich mich wiederhole, aber das ist für mich der Supergau. Bei meinen Maschinen ist der Vollzugriff auf alle Komponenten Grundvorraussetzung, Änderungen vornehmen zu können. Änderungen bedeuten i.d.R. bei mir, der Kunde will nicht nur eine geänderte, sondern eine zusätzliche Funktionalität. Das bedeutet oft einen zusätzlichen FB oder mindestens mal zusätzliche Parameter und damit verbunden zusätzliche Visualisierungsseiten oder -einträge. Ich habe bisweilen auch Änderungen, die mehr in den Bereich Fehlerbereinigung fallen, die ohne Visu-Änderung auskommen. Aber weitergehende Änderungen, da besteht doch meist (?) der Wunsch, auch in der Visu was dazuzutun? oder eben anzupassen?
Eine HMI-Variable im Schnittstellen-DB (als Kopie einer Prozeß-Variable) kann auch als IN/OUT-Variable von der HMI benutzt werden. Das muß man nur zusätzlich programmieren.
Bei Flexible ist ein Ein-/Ausgabefeld der Standard-Fall. Es ist vielleicht nicht der schönste Programmierstil, aber bei einem Stückzähler, bei dem es nicht auf jedes Teil ankommt, kann ja durchaus ein Zugriff sowohl von der CPU wie auch der HMI auf die gleiche Variable erfolgen. Trennt man nun diese einzige Variable in den Teil, auf den das HMI zugreifen soll und den Teil, auf den das Programm zugreifen soll, so ist in der Steuerung eine Abgleichsroutine notwendig. Ändert sich also der Inhalt eine der beiden Variablen, so muss diese Änderung auf die jeweils andere Variable rüberkopiert werden. Der Vorzug dieser Vorgehensweise liegt dabei auf der Hand: es kann klar ein Vorrang festgelegt werden, sollten sich beide Werte gleichzeitig ändern. Nachteil: es ist nicht unerheblich Code dafür notwendig.
Nur die Prüfung im Steuerungsprogramm vor der Verwendung garantiert mir zulässige Werte. Und nur, wenn die vernetzte Anwendung nicht auf die original-Zielvariable schreibt sondern auf eine Zwischenvariable. Nur dann kann das Steuerungsprogramm entscheiden, ob und wann es den Wert übernimmt.
Das schrieb auch ich heute mittag, dass ich sowas auch mache. Ich schrieb auch, dass ich diese Puffervariable nicht in einen Extra-DB lege. Ich gehe hier nochmals darauf ein, da ich mit Dir übereinstimme, dass zwischen der Prüfung und der Verwendung des Wertes einer Variablen ja zwischendurch noch ein HMI-Zugriff liegen könnte. Um also den zwischenzeitlichen Zugriff seitens der HMI zu verhindern, muss man also zunächst den Wert kopieren und dann anhand der Kopie überprüfen. Der Satz "Nur dann kann das Steuerungsprogramm entscheiden, ob und wann es den Wert übernimmt" bekommt dann allerdings in meinen Augen eine etwas abweichende Bedeutung. Die Prüfroutine muss zunächst den Wert holen und mindestens mal in eine Zwischenschublade schieben. Sollte also die Prüfroutine mehr seitens der HMI-Ein/Ausgabe angesiedelt sein, so ist dort eine besondere Sorgfalt durch eine weitere Puffervariable erforderlich. Ist die Prüfroutine mehr der Verarbeitungsseite zugeordnet, so kann direkt an der Kopie manipuliert werden oder ggf. die Verarbeitung ausgesetzt werden. Naja, wenn ich bei Dir weiterlese:
Wenn man nun für den ganzen OB1-Zyklus gleichbleibende HMI-Variablen braucht und vor allem garantieren will, daß sich eine HMI-Variable zwischen der Prüfung und der Verwendung nicht ändert, dann muß man quasi ein eigenes Prozeßabbild der HMI-Eingabevariablen erstellen. Das geht nur, wenn die HMI nicht direkt auf die Prozeßvariable schreibt, sondern auf eine Zwischenvariable (und die hat sich in einem Schnittstellen-DB zu befinden
).
dann sind wir uns doch eigentlich - vom Schnittstellen-DB mal abgesehen - doch eigentlich einig.
Dann war da noch die Sache mit dem Test der Visualisierung:
Dadurch, daß meine HMI-Variablen nur Kopien der Prozess-Variablen sind, kann ich sehr einfach die Verbindung der HMI-Variable zur Prozess-Variable im Schnittstellen-DB unterbrechen und statt dessen beliebige Werte in die HMI-Variable schreiben, ohne den laufenden Prozess zu beeinflussen und ohne das HMI-Projekt zu ändern.
Zitat von Perfektionist
ich behaupte jetzt ganz frech das Gegenteil: ich kann einen FB mitsamt seinem IDB und der für ihn erstellten Visu-Seite völlig losgelöst von irgendwelcher Rangiererei testen.
Kannst Du das auch im laufenden Betrieb, wenn Du das, was Du in der Visu testen willst, an der Anlage nicht schalten darfst?
An dieser Stelle haben wir, wie ich nun feststelle, vollständig aneinander vorbeigeredet. Ich bin von S7 und Flexible ausgegangen, Du offenbar von allem, was es auf dieser Welt so gibt. Und das muss ja nicht Flexible sein. Bei Flex sieht es so aus, dass da eigentlich nichtmal S7 installiert sein muss und ich auch keine lebende Steuerung brauch, um eine Visu testen zu können. Da kann man in der Manier einer Variablentabelle direkt in einem Testbetrieb am Erstellsystem die Variablen der Steuerung simulieren. Es ist also so, dass ich gar nicht das dringende Bedürfnis habe, im laufenden Betrieb testen zu können, da es alternative Möglichkeiten (bei Flex!) gibt.