TIA Fehlermeldungen PLC <-> HMI

[Nissandriver]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen,

ich habe eine S7-1500 und ein TP1200 Comfort. Wir benutzen WinCC Advance. Beim Lehrgang damals, hatte ich kurz Fehlermeldungen mit behandelt.

Bei den Fehlermeldungen muss ich ja immer dann schreiben , das was auslöst und dann Fehlermeldungen.Meldungen_Maschine.%X2 etc. geht das auch einfacher ? das ich nicht immer %x2, %x3 etc eingeben muss ?

Wir sind sonst in der NC Welt unterwegs.

Ich kann ja in der HMI ja nur Analogmeldungen und/oder Bit-Meldungen erstellen.

Hoffe ihr könnt mir helfen oder ein Tipp geben ?

Danke im Voraus

Gruß

Steven

 

[Botimperator]

Bei den Fehlermeldungen muss ich ja immer dann schreiben , das was auslöst und dann Fehlermeldungen.Meldungen_Maschine.%X2 etc. geht das auch einfacher ? das ich nicht immer %x2, %x3 etc eingeben muss ?

Du kannst die Bits bei Bitmeldungen per Slice-Zugriff adressieren, musst es aber nicht.
Beispielsweise kannst du auf SPS-Seite z.B. ein Array[1..512] of Bool nehmen, für das Triggern der Störmeldungen dessen Elemente Adressieren & als HMI-Variable dann das SPS-Array per Array[0..31] of Word überlagern.
Dann brauchst du in den HMI-Meldungen nurnoch die Triggervariable angeben & die Triggerbits fortlaufend nummerieren.

Am besten du legst die erste Meldung an & machst den Rest in Exel. (ist mit dem "runterziehen" einfacher).
Gleiches Spiel mit der PLC-Quittiervariable & der HMI-Quittiervariable, wenn jeweils benötigt.

Achtung:
das Numerieren der Triggerbits einer kompletten Struktur funktioniert in Unified nicht mehr, falls das für dich relevant sein sollte.
Da musst du dich immer konkret auf einen Basis-Datentyp beziehen & dessen Triggerbits adressieren.

Bei der Adressierung noch die im HMI gedrehte Endianess beachten & im Melde-Management der SPS Vorkehrungen für Flanken-Meldungen berücksichtigen (also wenn Meldungen kürzer als der Erfassungszyklus der HMI-Variable anstehen).

Ich kann ja in der HMI ja nur Analogmeldungen und/oder Bit-Meldungen erstellen.

Oder PLC-Meldungen per "Program_Alarm".
Die sind aber mit etwas Vorsicht zu genießen, Details siehe F1-hilfe & Forums-Suchfunktion.

 

[Nissandriver]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du kannst die Bits bei Bitmeldungen per Slice-Zugriff adressieren, musst es aber nicht.
Beispielsweise kannst du auf SPS-Seite z.B. ein Array[1..512] of Bool nehmen, für das Triggern der Störmeldungen dessen Elemente Adressieren & als HMI-Variable dann das SPS-Array per Array[0..31] of Word überlagern.
Dann brauchst du in den HMI-Meldungen nurnoch die Triggervariable angeben & die Triggerbits fortlaufend nummerieren.
Anhang anzeigen 93890
Am besten du legst die erste Meldung an & machst den Rest in Exel. (ist mit dem "runterziehen" einfacher).
Gleiches Spiel mit der PLC-Quittiervariable & der HMI-Quittiervariable, wenn jeweils benötigt.

Achtung:
das Numerieren der Triggerbits einer kompletten Struktur funktioniert in Unified nicht mehr, falls das für dich relevant sein sollte.
Da musst du dich immer konkret auf einen Basis-Datentyp beziehen & dessen Triggerbits adressieren.

Bei der Adressierung noch die im HMI gedrehte Endianess beachten & im Melde-Management der SPS Vorkehrungen für Flanken-Meldungen berücksichtigen (also wenn Meldungen kürzer als der Erfassungszyklus der HMI-Variable anstehen).


Oder PLC-Meldungen per "Program_Alarm".
Die sind aber mit etwas Vorsicht zu genießen, Details siehe F1-hilfe & Forums-Suchfunktion.

Danke für die schnelle Antwort.

wie mache ich das mit den Überlagern mit den SPS-Array of Word ? Per SCL?

Noch nie gemacht, sorry das ich frage.

 

[JesperMP]

Du kannst die Störmeldevariabeln nicht als WORD oder DWORD mit Überlagerung machen, sondern direkt als eine ARRAY von BOOLs.
Damit kannst du eine beliebig grossen Array erstellen, nicht nur bis 16 oder 32 Meldungen begrenzt.
Und dann sparst du dich die Überlagerung.

Ein Tip: Kopiere die Störmeldetexte von die HMI Alarme in die Kommentarfelder für die BOOLs in die SPS DB. Damit hast du kommentierte Störmeldungen in das Anwenderprogramm.

Noch nie gemacht, sorry das ich frage.

Dafür ist das Forum da.

 

[Nissandriver]

Du kannst die Störmeldevariabeln nicht als WORD oder DWORD mit Überlagerung machen, sondern direkt als eine ARRAY von BOOLs.
Damit kannst du eine beliebig grossen Array erstellen, nicht nur bis 16 oder 32 Meldungen begrenzt.
Und dann sparst du dich die Überlagerung.

Ein Tip: Kopiere die Störmeldetexte von die HMI Alarme in die Kommentarfelder für die BOOLs in die SPS DB. Damit hast du kommentierte Störmeldungen in das Anwenderprogramm.


Dafür ist das Forum da.

Habe jetzt eine UDT gemacht mit den Array o..511 of BOOL
IM DB dann Meldungen mit den den Datentypen angelegt und mit Meldungsword mit Array 0..31 of WORD .

Bei den BITMELDUNGEN der HMI kann ich nicht auf BOOL zugreifen

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

wie mache ich das mit den Überlagern mit den SPS-Array of Word ? Per SCL?

Überlagern im Sinne von gleiche Adresse, aber unterschiedliche Datentypen in SPS & HMI.

Beispiel aus meinem aktuellen Programm:
Auf SPS-Seite habe ich beispielweise zwei UDTs, die jeweils die Bool-Arrays für jede Baugruppe enthalten.

"sStm" sind dabei die im Störmelde-Baustein eigentlich angesteuerten Bits, während "sStmV" die Bits für die Visualisierung enthält.
In den Visualisierungs-Bits ist die Endianess gedreht & Meldungen werden auf mindestens eine Sekunde verlängert, damit das HMI auch Signalflanken registriert.
"sStmQ" enthält die Quittierbits für die Quittierung SPS => HMI (Quittierung HMI => SPS benutze ich hier nicht).
Im HMI findet sich dann ein Array, welches "sStmV" & "sStmQ" UDT mit einem Array of Word überlagert.

Und darauf beziehe ich mich dann bei den Bitmeldungen.


Der Baustein ist allerdings etwas "old fashioned" of Doom, wie viele der historisch gewachsenen Bausteine bei uns, die man noch nicht zwingend ersetzen musste ¯\_(ツ)_/¯
Ich denke das grobe Prinzip sollte klar sein, Details siehe F1-Hilfe im TIA und/oder hier im Forum (gibt diverse Treads darüber was und wie...).

Es wäre für dich vllt. sinnvoller wenn dein Meldungsmanagement-Baustein das Übersetzen von UDT of Array of bool auf Array of Word direkt in der SPS erledigt & dort auch die beiden Quittierbits handhabt.

 

[Nissandriver]

Überlagern im Sinne von gleiche Adresse, aber unterschiedliche Datentypen in SPS & HMI.

Beispiel aus meinem aktuellen Programm:
Auf SPS-Seite habe ich beispielweise zwei UDTs, die jeweils die Bool-Arrays für jede Baugruppe enthalten.
Anhang anzeigen 93904
"sStm" sind dabei die im Störmelde-Baustein eigentlich angesteuerten Bits, während "sStmV" die Bits für die Visualisierung enthält.
In den Visualisierungs-Bits ist die Endianess gedreht & Meldungen werden auf mindestens eine Sekunde verlängert, damit das HMI auch Signalflanken registriert.
"sStmQ" enthält die Quittierbits für die Quittierung SPS => HMI (Quittierung HMI => SPS benutze ich hier nicht).
Im HMI findet sich dann ein Array, welches "sStmV" & "sStmQ" UDT mit einem Array of Word überlagert.
Anhang anzeigen 93901
Und darauf beziehe ich mich dann bei den Bitmeldungen.
Anhang anzeigen 93907

Der Baustein ist allerdings etwas "old fashioned" of Doom, wie viele der historisch gewachsenen Bausteine bei uns, die man noch nicht zwingend ersetzen musste ¯\_(ツ)_/¯
Ich denke das grobe Prinzip sollte klar sein, Details siehe F1-Hilfe im TIA und/oder hier im Forum (gibt diverse Treads darüber was und wie...).

Es wäre für dich vllt. sinnvoller wenn dein Meldungsmanagement-Baustein das Übersetzen von UDT of Array of bool auf Array of Word direkt in der SPS erledigt & dort auch die beiden Quittierbits handhabt.

Ok , danke. Dann werde ich mal schauen . Das das mit den Quittierbits !

Danke für eure Hilfe

EDIT : Eine Frage habe ich aber noch..

Wollte eigentlich Fehler Maschine und Allgemein trennen. Aber mit der HMI wird das nicht so funktionieren oder ? Weil es ja von ID 1 los geht. Also wäre es besser alles in eins zu machen ? @Botimperator

 

[Botimperator]

Die Meldungen müssen eindeutig identifizierbar sein, also kannst du keine zwei Nummernkreise für die Melde-ID verwenden.
Du musst also "alles in eins" machen.

Bei uns ist das so gelöst, dass im Störmelde-UDT die Baugruppen jeweils als separates Array angelegt sind.
("Alg" => Allgemein, "Bel" => Beladung, usw)
Im Meldetext bekommen die Meldungen immer einen Präfix, passend zu Baugruppe & baugruppeninterner Nummer & unabhängig davon ob das Meldebit tatsächlich verwendet wird.

Und kannst das im SPS-Baustein auch einigermaßen sauber verräumen
(Das mit FUP ist ein Template bei uns, würde es bei einem Neubau eher mit SCL + Regions strukturieren)

Dann ist auch immer gleich klar woher die Meldung kommt, wenn mal eine Meldung ohne Meldetext hast.
Wie du so etwas angehst ist aber letztendlich eine Frage des firmeninternen Stils ¯\_(ツ)_/¯

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe jetzt eine UDT gemacht mit den Array o..511 of BOOL
IM DB dann Meldungen mit den den Datentypen angelegt und mit Meldungsword mit Array 0..31 of WORD .

Ja, ist korrekt. In die SPS, als eine ARRAY of BOOL. In die HMI als eine ARRAY of WORD.
Die einzelne Störmeldungen sind mit Trigger Bit-Nummer identifiziert, also 0..511.

Warum nicht als ARRAY of BOOL in die HMI, keine Ahnung. Ist halt so.

 

[Nissandriver]

Warum nicht als ARRAY of BOOL in die HMI, keine Ahnung. Ist halt so.

Das soll angeblich bei Unified anders sein, aber da bin ich mir nicht sicher..

Die Meldungen müssen eindeutig identifizierbar sein, also kannst du keine zwei Nummernkreise für die Melde-ID verwenden.
Du musst also "alles in eins" machen.

Bei uns ist das so gelöst, dass im Störmelde-UDT die Baugruppen jeweils als separates Array angelegt sind.
("Alg" => Allgemein, "Bel" => Beladung, usw)
Im Meldetext bekommen die Meldungen immer einen Präfix, passend zu Baugruppe & baugruppeninterner Nummer & unabhängig davon ob das Meldebit tatsächlich verwendet wird.

Ok danke, konnte ich mir fast denken! Aber gut zu wissen.