TIA Datenbaustein SPS-HMI Kommunikation

[Oskar72]

Zuviel Werbung?
-> Hier kostenlos registrieren

Liebe SPS Kollegen,

ich habe bis Dato für die Kommunikation zwischen SPS (S7-1500) und Unified Panel einen eigenen HMI-Datenbaustein angelegt. Ich könnte ja aber auch direkt aus dem HMI auf dien Daten im FB zugreifen. So würde ich mir eine doppelte Datenhaltung ersparen. Frage: Gibt es Gründe welche dagegen sprechen?
Liebe Grüße und besten Dank für die Antworten.

 

[DCDCDC]

Liebe SPS Kollegen,

ich habe bis Dato für die Kommunikation zwischen SPS (S7-1500) und Unified Panel einen eigenen HMI-Datenbaustein angelegt. Ich könnte ja aber auch direkt aus dem HMI auf dien Daten im FB zugreifen. So würde ich mir eine doppelte Datenhaltung ersparen. Frage: Gibt es Gründe welche dagegen sprechen?
Liebe Grüße und besten Dank für die Antworten.

Meinst du über den Instanzdatenbaustein?


Einen Hmi Datenbaustein brauchts ja nicht direkt.. deine Schnittstellen sind ja schon global definiert.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit dem extra HMI-Datenbaustein ist automatisch eine (hoffentlich vollständige) Dokumentation der HMI-Schnittstelle vorhanden. Besonders wichtig für "fremde" Programmierer, die irgendwann mal Support für das Programm machen müssen. Wenn man merkt, dass die HMI überall verstreut zugreift, muss man viel intensiver und langwieriger die Querverweise checken, bevor man irgendwelche Variablen im SPS-Programm verändern kann.

Wenn die HMI/Visu von einem anderen Bearbeiter erstellt wird, oder wenn die HMI mit einem nicht integrierten externen Programm erstellt wird, dann braucht man als Datenpunkt-Dokumentation nicht das ganze Projekt/Programm übergeben, sondern nur die HMI-DB. Stichwort: schlanker PLC-Proxy.

Mit HMI-DB kann man viel leichter die HMI/Visu im laufenden Betrieb testen/manipulieren, ohne die Funktion der Anlage zu beeinflussen, wenn man weiß, dass nur die HMI die Variablen liest.

Im Schaltschrankbau geht man von externen Kabeln auch nicht mit jeder einzelnen Ader direkt mitten in den Schrank auf Relais und Schütze und ... sondern auf Rangier-Klemmleisten. Für die saubere Übersichtlichkeit. Dieselbe Aufgabe haben HMI-DB.

 

[DCDCDC]

Es gibt ja auch Konzepte, wo eben Funktionsbausteine eine direkte Hmi Schnittstelle haben, welche abgegriffen wird.

 

[Oskar72]

Es gibt ja auch Konzepte, wo eben Funktionsbausteine eine direkte Hmi Schnittstelle haben, welche abgegriffen wird.

Ich denke so mache ich es z.Zt.: Ich übergebe dem FB beim In/out einen Struct, welchen ich im HMI-DB abgelegt habe

 

[Oskar72]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit dem extra HMI-Datenbaustein ist automatisch eine (hoffentlich vollständige) Dokumentation der HMI-Schnittstelle vorhanden. Besonders wichtig für "fremde" Programmierer, die irgendwann mal Support für das Programm machen müssen. Wenn man merkt, dass die HMI überall verstreut zugreift, muss man viel intensiver und langwieriger die Querverweise checken, bevor man irgendwelche Variablen im SPS-Programm verändern kann.

Wenn die HMI/Visu von einem anderen Bearbeiter erstellt wird, oder wenn die HMI mit einem nicht integrierten externen Programm erstellt wird, dann braucht man als Datenpunkt-Dokumentation nicht das ganze Projekt/Programm übergeben, sondern nur die HMI-DB. Stichwort: schlanker PLC-Proxy.

Mit HMI-DB kann man viel leichter die HMI/Visu im laufenden Betrieb testen/manipulieren, ohne die Funktion der Anlage zu beeinflussen, wenn man weiß, dass nur die HMI die Variablen liest.

Im Schaltschrankbau geht man von externen Kabeln auch nicht mit jeder einzelnen Ader direkt mitten in den Schrank auf Relais und Schütze und ... sondern auf Rangier-Klemmleisten. Für die saubere Übersichtlichkeit. Dieselbe Aufgabe haben HMI-DB.

Das mit Fremd-Programmierer ist ein gutes Argument.
Das mit dem externen Programm war für mich auch immer ein Argument - hat sich aber in der aktuellen Fa. erschlagen, da nur integriert...
Das mit dem Testen verstehe ich nicht ganz

 

[Oskar72]

Ich denke so mache ich es z.Zt.: Ich übergebe dem FB beim In/out einen Struct, welchen ich im HMI-DB abgelegt habe

oder meinst Du es anders?

 

[DCDCDC]

oder meinst Du es anders?

Wenn zu einem Funktionsbaustein Udts bzw Schnittstellen gehören, werden die ja auch global definiert.. darunter kann es dann auch eine Udt für die fürs Hmi relevanten Daten geben, dass du diese schon direkt in der Funktion übergibst, ohne noch mal zwingend einen Hmi Datenbaustein bzw eine Definition dafür im Hmi Datenbaustein anlegen zu müssen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Noch ein Punkt zu beachten: Multitasking / HMI Kommunikation ohne Zykluskontrollpunkt. Wenn im Programm mehrmals auf HMI-Variablen zugegriffen und womöglich sogar mehrmals drauf geschrieben wird, dann können die Werte "flackern". Mit Kopien der HMI-Werte in HMI-DB flackern die Werte nicht. Ein separater HMI-DB hat da quasi die Funktion eines "Prozessabbild der HMI".
Strukturen In/Out werden als Referenz übergeben. Wird im FB mehrmals auf die Werte zugegriffen, dann können sich die Werte zwischendurch ändern! Man kann z.B. einen HMI-Eingabewert auf Grenzwerte Min/Max prüfen und ggf. korrigieren, und beim Lesen für die eigentliche Verwendung des Wertes hat der dann doch einen unzulässigen Wert, weil er sich genau nach der Prüfung geändert haben kann!

 

[PN/DP]

Das mit dem Testen verstehe ich nicht ganz

Wenn man eine bomforzionöse aufwendige Visu mit z.B. vielen Farbumschlägen oder vielen symbolischen Ausgaben erstellt hat, dann muss man natürlich auch ausführlich testen. Oder man braucht für die Dokumentation Bildschirmausdrucke mit bestimmten Anzeigewerten. Das geht sehr einfach und auch im laufenden Betrieb der Anlage, wenn man die Variable im HMI-DB direkt manipulieren kann, ohne Angst, dass womöglich das SPS-Programm den manipulierten Wert irgendwie liest und verarbeitet.

 

[GrauesHaar]

Ich finde die Diskussion interessant. Für mich war es immer eine Selbstverständlichkeit, daß die Visu auf die Adressen zugreift, in denen die Daten gebraucht werden.
Hauptgründe:
1.) Wie soll ich durch Umkopieren eine E/A-Variable korrekt mit Daten versorgen?
Beispiel: Sollwerte werden durch einen Rezept-Transfer geladen. Später soll der Bediener die Sollwerte aber überschreiben können.
2.) Das Umkopieren der Daten (künstlich geschaffene Arbeit) entfällt.

Ich erkenne durchaus den Vorteil, eine sauber dokumentierte Schnittstelle zu haben. Aber wie löst man 1.)?

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Grundsätzlich sehe ich das genauso wie @PN/DP in #3.

Es gibt ja auch Konzepte, wo eben Funktionsbausteine eine direkte Hmi Schnittstelle haben, welche abgegriffen wird.

Wir haben betriebsintern noch die Konvention eines HMI-UDTs mit fest definierten Namen in den Static-Variablen von FBs.
Der heißt immer gleich & damit ist immer klar, dass hier Daten mit dem HMI ausgetauscht werden & entsprechende Absicherungen bei Verwendung der dort enthaltenen Variablen angewendet werden müssen.
Das finde ich für klein Anlagen mit max. einem HMI noch ok.
Bei mehreren HMIs, die auf die gleiche Instanz zugreifen, kann das Debugging lustig werden.

Ansonsten gilt grundsätzlich:
Haken für hmi-zugriff der Variablen immer aus & nur bei explizit gewünschten Zugriffen diese setzen.
Das vermeidet schon die meisten Fehler, auf die DA006 des Siemens-Styleguides Bezug nimmt.

1.) Wie soll ich durch Umkopieren eine E/A-Variable korrekt mit Daten versorgen?
Beispiel: Sollwerte werden durch einen Rezept-Transfer geladen. Später soll der Bediener die Sollwerte aber überschreiben können.

Ich glaube, ich weiß worauf du hinaus willst, das Beispiel hinkt aber etwas.
Speziell Rezepte würde ich immer über separate DBs austauschen.
Das Runterschreiben der Rezeptdaten kannst du über den Synchronisierungszeitpunkt der Rezepturvariablen handeln & das manuelle ändern über einen parallelen Zugriff per HMI-Variable auf die SPS-Seite der Rezepturvariablen.

2.) Das Umkopieren der Daten (künstlich geschaffene Arbeit) entfällt.

Ich würde das nicht als künstlich geschaffenen Arbeit betiteln.
Eine sauber organisierte Schnittstelle ist beim Erstellen immer etwas mehr Aufwand als die Quick&Dirty-Variablenverdrahtung direkt ins HMI.

Gibt genug Möglichkeiten den Datenfluss klar strukturiert zu organisieren.
Bei kleineren Projekten mag das praktikabel sein direkt in die Instanz-DBs zu gehen, und ggf. tatsächlich Aufwand einsparen, aber spätestens bei mehr als einem HMI an einer SPS fällst du mit den Direktzugriffen schnell auf die Schnauze (Thema "wer hat jetzt die Wertänderung ausgelöst?").

 

[xMisterDx]

Man muss doch als externer Programmierer, der ein fremdes Programm warten soll, ohnehin alle Querverweise checken. Selbst wenn ein HmiDb vorhanden ist... wer garantiert dem Programmierer denn zu 110%, dass tatsächlich nur auf diese Daten zugegriffen wird? Kann ja doch mal einer irgendwas schnell reingefummelt haben. Und am Ende ist das ja auch nicht mein Bier, wir müssen es dem Wettbewerb nicht leichter machen als es sein muss, in unseren Programmen zu fummeln
Gilt natürlich nur solange der Kunde das Programm so abnimmt... ist ja selbstverständlich...

Es zwingt einen auch keiner, nach dem Standard von Siemens zu arbeiten. Wichtig ist nur, dass man einen Standard hat, den durchhält und ordentlich dokumentiert. Du kannst ja im stat-Bereich kennzeichnen, ob eine Variable von extern geschrieben wird und/oder geschrieben werden darf. Beim HMI-Zugriff kann man das ja sogar direkt im DB erlauben oder sperren. Wer beim direkten Zugriff auf Lokaldaten schlampt, der schlampt am Ende auch beim separaten GDB fürs HMI.

Klar kann man jede Variable 2-3 mal im Kreis herumschieben und in 3 verschiedenen GBDs verteilen, damit andere darauf zugreifen dürfen, gemäß Programmierleitfaden. Dann brauchst im Zweifel halt ne größere CPU, weil die Zykluszeit ausufert.

 

[PN/DP]

Und am Ende ist das ja auch nicht mein Bier, wir müssen es dem Wettbewerb nicht leichter machen als es sein muss, in unseren Programmen zu fummeln

Man kann es natürlich auch den eigenen Kollegen möglichst schwer machen, das Programm zu verstehen, dann bekommt man vielleicht ehrfürchtige Anerkennung ...

 

[GrauesHaar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube, ich weiß worauf du hinaus willst, das Beispiel hinkt aber etwas.

Ja, du hast recht. Das Beispiel war schlecht.
Ich versuch's daher nochmal:
Wie soll ich durch Umkopieren eine E/A-Variable korrekt mit Daten versorgen?
Beispiel: Eine Variable kann sowohl von der SPS als auch durch den Bediener verändert werden. Das ist ja der typische Ahwendungsfall einer E/A- Variable.
Ich hatte da mal einen Kollegen, der hat tatsächlich den Wert der Visu auf Änderung überwacht und bei Änderung den Visu-Wert auf eine andere Adresse, außerhalb des Visu-DBs kopiert. Und andere Richtung: Bei Änderung durch die SPS den Wert in den Visu-DB kopiert. Wie man sich denken kann, hat das auch meistens funktioniert ;-). Der klassische Manchmalfehler.

Ich sehe da keine andere Lösung als
1. E/A-Variable verbieten oder
2. Einen Schnittstellen-DB für die Visu verbieten

Was übersehe ich/ habe ich nicht verstanden?

 

[Botimperator]

Und am Ende ist das ja auch nicht mein Bier, wir müssen es dem Wettbewerb nicht leichter machen als es sein muss, in unseren Programmen zu fummeln

Oder dem Kunden...
Oder deinen Kollegen...
...die dann im Zweifelsfall mist bauen / pfuschen, weil sie deine Arbeitsweise (und damit deinen "Standard") nicht verstehen.

Man muss doch als externer Programmierer, der ein fremdes Programm warten soll, ohnehin alle Querverweise checken.

Bei kleinen Projekten mit <10 CPUs/Panels mag das noch realistisch machbar sein....
Und Querverweise sind beispielweise bei CPU seitigen Multiplex-Schnittstellen nur ein Teil der Miete.

Siehe Siemens LBP-Bibliothek.
Diese ist ein hybrid aus einem zentralen Multiplex-Baustein für die HMI-Menüs & Zugriffen auf die Instanz-DBs für die Symbole in den Übersichtsbildern.
Sowas ist richtig geil in der Anwendung, aber ohne (gute!) Doku hast du da verloren.

Klar kann man jede Variable 2-3 mal im Kreis herumschieben und in 3 verschiedenen GBDs verteilen, damit andere darauf zugreifen dürfen, gemäß Programmierleitfaden. Dann brauchst im Zweifel halt ne größere CPU, weil die Zykluszeit ausufert.

Wieso eigentlich herumschieben?
Die Werte über die InOut-Variablen als CallByReference übergeben & die SPS muss kein einziges Bit rumkopieren.

Was übersehe ich/ habe ich nicht verstanden?

Möglicherweise das die Art und Weise ein HMI anzubinden etwa der Fragestellung "was ist der beste Wein?" ähnelt.
Es ist schlicht eine Frage der Anforderungen, der Projektgröße, wie viele Programmierer aus wie vielen Sprachen daran mitarbeiten und schlussendlich auch eine Frage des persönlichen oder des unternehmensinternen Stils.

 

[DCDCDC]

oder des unternehmensinternen Stils.

oder des Lastenhefts, oder.., oder.., oder..

Da gibts zu viele Möglichkeiten!