WinCC Grundsatzfrage zur Kommunikation zwischen HMI und SPS

[elmum]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe zurzeit eine grundsätzliche Fragestellung, wie ich die Kommunikation zwischen HMI und SPS aufbaue.

Leider habe ich bei mir im Unternehmen keinen Ansprechpartner, da ich Alleinunterhalter bin.
Auch bei der Mutter bekomme ich nicht wirklich Support. Man hat mir da mal gesagt, dass das jeder macht, wie er meint.
Und wenn es läuft, dann läuft es halt.

Ich möchte vermeiden, dass wenn jemand mal ins Projekt schaut, der meint das da ein Gärtner am Werk war.

Von daher mache ich mir zurzeit Gedanken, wie man die Schnittstelle zwischen Touch und SPS aufbaut.

Ich habe hier schon gelesen, dass es eine Möglichkeit ist, die Kommunikation über einen bzw. zwei Datenbausteine laufen zu lasssen.
Also alles was von der SPS kommt über eine Datenbaustein ins Touch zu schleusen und umgekehrt.

Oder ist es schlauer einfach auf die SPS vom Touch aus direkt zu zugreifen?

Mich würden da Tipps und Tricks oder Vorlieben interessieren.

Ich weiß, dass ich meinen eigenen Weg finden muss. Aber vielleicht gibt es ja eine Richtung im Aufbau den man
am besten wählen kann.

Würde mich über Tipps und Trick und Meinungen freuen.

Gruß

der elmum

 

[Januar]

Ich habe mir prinzipiell angewöhnt, einen HMI-DB zu erstellen, in dem alles geregelt wird, was mit der Visu zu tun hat. Wenn es eine umfangreichere Kommunikation ist, mache ich meist 2 DBs daraus, einen für SPS→HMI, einen für HMI →SPS.

Das macht das Lesen einfacher, weil auf den ersten Blick erkennbar ist, was ein HMI-Befehl und was Programm-errechnet ist.

Außerdem empfehle ich die Siemens Style-Guides, da steht bestimmt auch einiges zu dem Thema drin.

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Welches HMI und welche SPS verwendest du ?

 

[schwimmer]

Gehe auch den Weg über den separaten HMI-DB. Bei bestimmten Funktionen, z.B. um Daten zu archivieren mache ich dann noch einen eigenen Baustein mit Instanz-DB auf und greife dann direkt auf den Instanz-DB zu und schiebe die Daten nicht nochmal in einen weiteren DB

 

[elmum]

@de vliegende hollander : Ich benutze eine SIMATIC PC Station, wo WinCC RT Advanced läuft und als SPS habe ich eine S7-315 DP2. Ist alles noch aus Altbeständen zusammengesucht. Darf halt alles nix kosten. Daher kommen dann so alte Sachen zum Einsatz.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Außerdem empfehle ich die Siemens Style-Guides, da steht bestimmt auch einiges zu dem Thema drin.

da steht vermutlich, "ziehe mit der Maus einfach ne Variable aus der SPS ins Visubild" fertig...

Also ein/mehrere standardisierte DBs zur Kopplung ans HMI/Leitsystem machen auf jeden Fall sind.

Wenn die DBs in der SPS für die Automatisierungsfunktionen Standardisiert sind, kann das HMI auch darauf zugreifen, sogar auf IDBs, aber nur wenn die sich nicht ständig ändern...

Auf Merker oder E/As NIE zugreifen...

 

[elmum]

Dann bin ich da schon auf den richtigen Weg.

Das beruhigt schon mal.

Wie macht ihr das eigentlich, wenn, ich weiß nicht genau wie ich es beschreiben soll, eine Tasterschaltung programmieren wollt?

Ich benutze da im HMI die Funktion "invertiereBit".
Wenn ich Funktionen habe, die diese Tasterschaltung beeinflussen, setze ich das Bitte dementsprechend bei Bedarf zurück.

Oder schieße ich mir da ins Bein?

 

[elmum]

@ducati : Warum nicht auf Merker zugreifen? Ich frag mal einfach, auch wenn man mich dann steinigt

Wenn nicht auf Merker & E/As zugegriffen werden soll, dann ist es ja eigentlich auch Pflicht einen HMI-DB zu erstellen.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

@ducati : Warum nicht auf Merker zugreifen? Ich frag mal einfach, auch wenn man mich dann steinigt

weil Du dann in Querverweisen in der SPS nicht siehst, dass der E0.0 z.B. auch in der Visu verwendet wird. Wenn jetzt mal jemand den Eingang für was anderes verwendet, krigst halt nicht mit, dass Du die Visu auch ändern musst. Bei Merkern könntest Du natürlich nen Bereich definieren wo die Visu drauf zugreift, aber dann kannst gleich nen DB anlegen

Wenn nicht auf Merker & E/As zugegriffen werden soll, dann ist es ja eigentlich auch Pflicht einen HMI-DB zu erstellen.

Naja wie gesagt, Du hast nen standardisierten Motor-FB, der sich nicht mehr ändert, dieser wird identisch 50mal im Programm verwendet. Da könnte die Visu schon auch auf die InstanzDBs zugreifen... Aber schön ist das nicht, also besser die fürs HMI benötigten Daten über nen UDT als INOUT in nen separaten Global-DB rangieren...

 

[schwimmer]

Was meinst du denn mit "Tasterschaltung"?
Wenn aus der HMI etwas geschaltet werden soll, wie mit einem Taster, dann nehme ich SetzeBitInVariable bei Drücken und RücksetzeBitInVariable beim Loslassen der Schaltfläche. Finde ich am sichersten, alles andere macht dann die SPS

 

[ducati]

Wie macht ihr das eigentlich, wenn, ich weiß nicht genau wie ich es beschreiben soll, eine Tasterschaltung programmieren wollt?

Ich benutze da im HMI die Funktion "invertiereBit".
Wenn ich Funktionen habe, die diese Tasterschaltung beeinflussen, setze ich das Bitte dementsprechend bei Bedarf zurück.

Oder schieße ich mir da ins Bein?

Das passt schon so... aber besser wären 2 Taster in der HMI, einen zum Einschalten und nen zweiten zum Ausschalten...

 

[elmum]

Zuviel Werbung?
-> Hier kostenlos registrieren

@schwimmer : Ich meinte eine klassische Selbsthaltung.

 

[schwimmer]

Ich meinte eine klassische Selbsthaltung.

Würde ich immer in der SPS realisieren, nicht im HMI
Vom Panel nur der reine Taster, Bit high bei gedrückt, Bit low wenn nicht gedrückt

 

[ducati]

@schwimmer : Ich meinte eine klassische Selbsthaltung.

Naja, ich versuche es mal zu skizzieren, aber vermutlich verwirrend...

- Du hast nen FB mit IDB für irgendeine Aufgabe
- in dem FB nen INOUT mit nem UDT
- der UDT beinhaltet nen BOOL LAMPE_EIN_VON_HMI und nen BOOL LAMPE_AUS_VON_HMI
- du legst nen Global-DB (HMI-Kopplung) an welcher auch dieses UDT beinhaltet
- den INOUT vom FB beschaltest Du mit dem Global-DB
- im HMI hängt an der einen Taste die Variable vom Global-DB LAMPE_EIN_VON_HMI (setze Bit bei Drücken)
- im HMI hängt an der anderen Taste die Variable vom Global-DB LAMPE_AUS_VON_HMI (setze Bit bei Drücken)

- im FB liest Du LAMPE_EIN_VON_HMI und setzt ne statische Variable und dann LAMPE_EIN_VON_HMI=: FALSE
- im FB liest Du LAMPE_AUS_VON_HMI und rücksetzt ne statische Variable und dann LAMPE_AUS_VON_HMI=: FALSE


PS: kommt n bissl auch drauf an, ob Du den FB jetzt einmal oder mehrmls verwenden willst...
...

 

[elmum]

Zuviel Werbung?
-> Hier kostenlos registrieren

@schwimmer : Ich würde dann für eine Selbsthaltung einen FB programmieren, der die Funktion bereitstellt.
Und den FB dann in anderen FB's aufrufen.

Oder ist das falsch gedacht?

Und gibt es einen Trick oder spezielle Weise, wie ich diese Selbsthaltung realisiere?
Ich würde das dann auch in FUP programmieren.
Wobei man mir mal gezeigt hat, dass das in AWL wesentlich kürzer geht.
Ich aber nicht so firm in AWL bin

 

[schwimmer]

So ganz verstehe ich nicht was du meinst, du willst für die Selbsthaltung von einem Bit einen extra FB projektieren und den dann x-mal aufrufen? Warum denn das?
Es gibt keinen Trick oder keine spezielle Weise für eine Selbsthaltung, du musst von Fall zu Fall entscheiden wie die Selbsthaltung aussehen und umgesetzt werden muss. Eventuell muss die Selbsthaltung ja auch durch einen Fehler zurückgesetzt werden. Wie gesagt, InvertiereBit nutze ich nicht, da können dir auch immer mal ungewollte Schaltzustände entstehen, z.B. wenn du etwas überträgst und deine DBs reinitialisiert oder auf Startwerte gesetzt werden.
Wie du das umsetzt ob FUP, KOP, AWL oder SCL bleibt ganz deiner Vorliebe überlassen, sofern es nicht vom Kunden vorgeschrieben wird.

 

[ducati]

Ich könnte Dir schnell nen Beispielprojekt basteln, Step7 Classic oder TIA?

PS: in classic, mal so als Anregung, wie ich nen HMI-DB aufbauen würde...

 

[spstiger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kann mich dem nur anschließen. Ich würde auch versuchen, so viel Logik wie möglich in die SPS zu bringen und lieber weniger Logik im HMI zu machen. Wir haben manchmal Kunden, die versuchen halbe SPS-Anwendungen in den HMI zu programmieren, weil sie das manchmal einfacher zugänglich finden oder weil sie nur HMI programmieren und die SPS fest ist. Das wird dann aber schnell sehr unübersichtlich und wenn es dann zu komischem Verhalten kommt, dann ist man lange am Suchen, ob das Problem in der SPS oder im HMI ist.

Wir bauen bei unseren Projekten zum Teil sogar bestimmte Anzeige-Logiken (Schalter aktiv oder inaktiv etc.) lieber in der SPS und verknüpfen es dann im HMI. Dazu erzeugen wir dann oft eine Subroutine nur für Anzeige- und Bedienlogiken. Das ist oft einfacher zu warten und zu verstehen, als verteilte Verriegelungslogiken etc. im HMI, die ich oft sehe.

Noch ein Tipp zur Kommunikation zwischen HMI und SPS. In der Regel ist es ok, wenn die Kommunikation vom HMI ausgeht. Bei verteilten Systemen, mit einer Steuerung und vielen HMI, die synchron laufen sollen, nutzen unsere Kunden oft die SPS als Kommunikationsmaster z.B. als Modbus TCP Client (=Master) und die HMI nur als Slave (= Server).

 

[elmum]

@ducati : Vielen Dank für das Beispielprojekt. Soweit hab ich die Vorgehensweise verstanden.

Werde mal schauen, wie ich das am Besten in mein Projekt einarbeite bzw. das Projekt umarbeite.