TIA Program_Alarm separieren auf mehreren HMI

[Platinum]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich hab vor einiger Zeit angefangen unsere Standardbausteine (Ventile, Antriebe, etc.) auf das Meldeverfahren via Program_Alarm umzusetzen.

In den jeweiligen FB´s werden die Meldungen generiert und mittels Textliste, die unter den "PLC-Meldetextlisten" hinterlegt sind entsprechend angezeigt.
Klappt auch alles tadellos.

Jetzt zum Problem:
Aktuel habe ich 2 HMI (TP1200 Comfort, 2 Anlagenteile) in einem neuen Projekt, wo nicht jede Meldung in beiden Panels angezeigt werden soll.
In den FB´s lege ich die Meldeklasse fest, die ja immer gleich ist.

Habt Ihr eine Idee wie ich entscheiden kann, wie ich z.B. die Störung von einem Ventil nur auf Panel 1 und die andere nur auf Panel 2 anzeigen lasse?
Ich könnte jetzt die FB´s kopieren und dem neuen eine andere Meldeklasse geben. Finde ich persönlich aber nicht so schön.

Vielen Dank für eure Unterstützung.

Tia Portal V16
TP1200 Comfort
CPU 1518F-4 PN/DP

Gruß Willi

 

[maxder2te]

Dafür wirst du wohl keine Lösung finden ohne die FBs zu kopieren und die Meldeklassen zu ändern.

Ich bin in der Vergangenheit an ähnliche Grenzen gestoßen und wir haben uns dann entschieden, die Meldungsgenerierung wieder aus den Standard-FBs herauszulösen. Die Program_Alarm Instanzen werden wieder global an Hand einer Vorlage aus der Projektbibliothek heraus programmiert, für die Versorgung mit Begleitwerten und Meldungstrigger sind entsprechende standardisierte Schnittstellen kreiert worden.

lg

 

[Mecha2211]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie wäre ein Meldefilter in den Panels?
Meldeanzeigen und -Zeilen können ja mit einer Filtervariablen (Dynamisch) ausgestattet werden, die als Textsuche fungiert (weiß nicht genau ob in der ganzen Meldung oder nur im Meldetext).
Da könntest Du doch in der Referenzkennzeichnung im Meldetext Filter setzen.

 

[Platinum]

Vielen Dank für Eure Ansätze.
War eigentlich auch recht zuversichtlich bisher was die Meldungsgenerierung über den Program_Alarm angeht,
weil es einfach den Programieraufwand in Zukunft erheblich verringert.

Aber Grenzen gibt es halt überall.

Danke Euch

Gruß Willi

 

[Mecha2211]

Hilft Dir der Meldefilter nicht?

 

[Platinum]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jaein,

nehmen wir mal das Ventil z.B.
Wenn ich in jedem Analgeteil ein Ventil habe, dann heißt das eine "Ventil-1" das andere "Ventil-2" (am FB liegt ein String am Input, der den Namen des Ventiles in der Meldung ausgibt).
Mein Problem ist, nach was sollte ich da filtern? Die Texte in dem FB sind immer gleich und liegen in einer Textliste.

Ich könnte jetzt den Filter nur machen, wenn ich davor z.B. "Anlagenteil-1" und "Anlagenteil-2" mache.
Aber anscheind schreibt das Panel trotzdem die Meldung in den Meldepuffer von beiden Panels rein (so in der Hilfe gelesen).

Schön wäre, man könnte die Meldeklasse außen am FB noch anlegen und dort bestimmen

Gruß Willi

 

[ducati]

War eigentlich auch recht zuversichtlich bisher was die Meldungsgenerierung über den Program_Alarm angeht,
weil es einfach den Programieraufwand in Zukunft erheblich verringert.

Aber Grenzen gibt es halt überall.

Hmm, naja, was man hier so über den Program_Alarm liest, spart das aber auch nur bedingt Zeit

Ich hab früher mit 300/400er viel mit Alarm_DQ gearbeitet, hat schon was, aber auch wesentliche Nachteile.

Aktuell haben wir einen ziemlich guten Standard mit Bitmeldungen, der universell und auch einfach und schnell zu händeln ist. So nen Global-DB wo alle Meldungen immer drin sind, hat schon was... Egal ob für Visu, Fremdsystem oder Verwendung in der SPS selbst...

Zumindest denke ich ist es in 10 Jahren leichter für einen Fremden bei den Bitmeldungen durchzublicken als bei dem Program_Alarm.

Aber ist sicherlich alles Ansichtssache.

Gruß.

 

[Mecha2211]

Stimmt, im Meldepuffer landet die Meldung trotzdem.
Aber auch den Meldepuffer könntest Du filtern

Okay, wenn Du keine Anlagenbezeichnungen oder anderen Referenzen hast, nach denen Du filtern könntest, bringt es nichts.

Jaein,

nehmen wir mal das Ventil z.B.
Wenn ich in jedem Analgeteil ein Ventil habe, dann heißt das eine "Ventil-1" das andere "Ventil-2" (am FB liegt ein String am Input, der den Namen des Ventiles in der Meldung ausgibt).
Mein Problem ist, nach was sollte ich da filtern? Die Texte in dem FB sind immer gleich und liegen in einer Textliste.

Ich könnte jetzt den Filter nur machen, wenn ich davor z.B. "Anlagenteil-1" und "Anlagenteil-2" mache.
Aber anscheind schreibt das Panel trotzdem die Meldung in den Meldepuffer von beiden Panels rein (so in der Hilfe gelesen).

Schön wäre, man könnte die Meldeklasse außen am FB noch anlegen und dort bestimmen

Gruß Willi

 

[Platinum]

Zuviel Werbung?
-> Hier kostenlos registrieren

Trotzdem guter Ansatz

Ja mit dem Meldepuffer zusätzlich filtern wäre eine Möglichkeit.
Ich könnte ja "M1" und "M2" davor setzen, dann wären die Filter auf den jeweiligen Anlagenteil wirksam.

 

[MFreiberger]

Moin ducati,

Hmm, naja, was man hier so über den Program_Alarm liest, spart das aber auch nur bedingt Zeit

Ich hab früher mit 300/400er viel mit Alarm_DQ gearbeitet, hat schon was, aber auch wesentliche Nachteile.

Aktuell haben wir einen ziemlich guten Standard mit Bitmeldungen, der universell und auch einfach und schnell zu händeln ist. So nen Global-DB wo alle Meldungen immer drin sind, hat schon was... Egal ob für Visu, Fremdsystem oder Verwendung in der SPS selbst...

Zumindest denke ich ist es in 10 Jahren leichter für einen Fremden bei den Bitmeldungen durchzublicken als bei dem Program_Alarm.

Aber ist sicherlich alles Ansichtssache.

Gruß.

mit dem, was Du schreibst hast Du Recht.
Allerdings gehe ich davon aus, dass die 'Alarme' die Zukunft sind. Auch deswegen, weil diese im OPC UA-Standard definiert sind. Zudem hat SIEMENS angekündigt, die Alarme auf dem OPC UA-Server der 1500er Steuerung zur Verfügung zu stellen.

Aus meiner Sicht ist es nur eine Frage der Zeit, bis Alarme (statt Bitmeldungen) eingefordert werden. Das ist natürlich branchenabhängig und kommt darauf an, ob eine Steuerung autark arbeitet oder vernetzt ist.

VG

MFreiberger

 

[ducati]

Aus meiner Sicht ist es nur eine Frage der Zeit, bis Alarme (statt Bitmeldungen) eingefordert werden.

Naja, oder es ist eine Frage der Zeit, bis alle merken, was das für ein Quatsch ist...

Dadurch wird alles mit allem verquickt, und wenn man in 10 Jahren mal ein Panel tauschen muss, funtkioniert das neue Panel nicht mehr mit dem alten Program_Alarm der SPS...

Also alle 10 Jahre die gesamte Anlagensteuerung erneuern, das ist das große Ziel was dahinter steckt Und natürlich allen kleinen Annbietern das Leben schwer zu machen, die bisher einfach per OP-Kommunikation PUT/GET auf nen nichtoptimierten Global-DB zugreifen konnten.

Aktuell ist vieles im Umbruch, zum besseren weiss ich nicht, und wo die reise hingehen wird, ist nicht absehbar...

Aber OT

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin ducati,

Dadurch wird alles mit allem verquickt, und wenn man in 10 Jahren mal ein Panel tauschen muss, funtkioniert das neue Panel nicht mehr mit dem alten Program_Alarm der SPS...

das kann natürlich sein. Aber wenn SIEMENS die Alarme nach OPC UA-Standard aufbaut, sollte es dann sogar egal sein von welchem Hersteller das Ersatzpanel ist (Projektierung mal außen vor). Aber wahrscheinlich ist es i.M. noch nicht nach Standard umgesetzt, so dass Du nach aktuellem Stand Recht hast.
Wir sollten das Thema mal in eine Zeitkapsel packen und nach 10 Jahren wieder ausgraben

VG

MFreiberger