TIA TIA 1500er Meldungen

[SPSSchlumpf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe hier das erste grössere Projekt mit TIA und einer 1500er. Es geht um die Anbindung von mehrern Wincc Advanced und einem comfort Panel. Ich überlege gerade, ob ich mit dem alten Bitmeldeverfahren arbeiten soll, oder die Möglichkeit der 1500er und ProgramAlarme nutze. Dazu stellen sich mir folgende Fragen:

1. Kann ich bei dem Verfahren eine Meldung erzeugen und in der Meldung einen Text aus einer Textliste einfügen? Konkret: Ein Antrieb (von über 30) gibt mir eine Fehlernummer raus. Nun möchte ich nicht für jede Achse und Fehlernummer eine eigenen Meldung mit Text erzeugen, sondern eine Meldung pro Antrieb. In dieser soll Fehlertext als Tag (so wäre es bei Flex) aus einer Symbolliste entnommen werden.
Geht das?

2. Wie sieht es mit der Performance aus? Ist das Verfahren langsamer als das Bitmeldeverfahren? Lässt sich Bitmeldeverfahren und ProgramAlarm mischen?

Gibt es sonst noch Bugs und Irritationen die man beachten müsste? Das Projekt ist recht umfangreich und wenn ich mich für das neue Verfahren entscheide wäre ein späterer Wechsel mit viel Arbeit verbunden.

Danke!

 

[MFreiberger]

Moin SPSSchlumpf,

1. Kann ich bei dem Verfahren eine Meldung erzeugen und in der Meldung einen Text aus einer Textliste einfügen? Konkret: Ein Antrieb (von über 30) gibt mir eine Fehlernummer raus. Nun möchte ich nicht für jede Achse und Fehlernummer eine eigenen Meldung mit Text erzeugen, sondern eine Meldung pro Antrieb. In dieser soll Fehlertext als Tag (so wäre es bei Flex) aus einer Symbolliste entnommen werden.
Geht das?

Ja, das geht. Meines Wissens gibt es i.M. zwei Syntax-Möglichkeiten. Dabei musst Du den Program_Alarm programmieren und an die Begleitwerte entsprechende Variablen antragen, die dann Text oder Werte enthalten. Für eine Textliste musst Du eine Variable vom Datenmtyp WORD anlegen, die den INDEX des Textlisteneintrags enthält. Unter "PLC-Meldetextlisten" erstellst Du Deine Textlisten.
Syntax:
@n%t#<TEXTLISTE>@ // n = Begleitwertnummer vom Program_Alarm-Baustein / <TEXTLISTE> = Deine Textliste
oder über das Kontextmenü:
<Textliste: <Deine Textliste>: tag1> // gilt nur für die 1500er und geht nur über das Kontaxtmenü. Als tag1 werden Dir die Variablen angezeigt, die Du als Begleitwerde an Dein Program:Alarm übergeben hast.

2. Wie sieht es mit der Performance aus? Ist das Verfahren langsamer als das Bitmeldeverfahren? Lässt sich Bitmeldeverfahren und ProgramAlarm mischen?

Mischen würde ich es nicht (habe ich auch noch nicht ausprobiert). Performanceeinbußen konnten wir noch nicht feststellen (aber die Menge der Meldungen hält sich bei uns NOCH in Grenzen). Der Vorteil vom ProgramAlarm ist eindeutig die einmalige Projektierung. Dann ist es auf allen Panels gleich und man hat nicht für die gleiche Meldung unterschiedliche Text (mit oder ohne Rechtschreibfehlern ).

VG

MFreiberger

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

2. Wie sieht es mit der Performance aus? Ist das Verfahren langsamer als das Bitmeldeverfahren? Lässt sich Bitmeldeverfahren und ProgramAlarm mischen?

Gibt es sonst noch Bugs und Irritationen die man beachten müsste? Das Projekt ist recht umfangreich und wenn ich mich für das neue Verfahren entscheide wäre ein späterer Wechsel mit viel Arbeit verbunden.

Im Vergleich zum reinen Bitmeldeverfahren hast du bei sehr vielen Meldungen einen Performanceverlust, der im einstelligen Prozentbereich liegt. Die Vorteile liegen aber auf der Hand. Vor allem wenn an der CPU der Webserver aktiv ist, bekommst du deine Fehlermeldungen schon ohne Visu am Webserver angezeigt.

Wenn du schlau anfängst, lässt sich prinzipiell auch schnell wieder auf das Bitmeldesystem wechseln, vor allem wenn du Visualisierungen nutzen möchtest, die nicht von Siemens kommen.

Ich hab mir beispielsweise angewöhnt, dass ich meine Meldungen in ein Bool-Array lege - für jede Fehlerklasse oder jeden Fehlerbereich ein eigenes Array. Die Kommentare der Array-Elemente lassen sich ab V14 SP1 einzeln beschriften, wodurch jede Fehlermeldung sauber bezeichnet werden kann. Anschließend lege ich in einem FB ein Array von ProgramAlarm-Instanzen an und löse den ProgramAlarm mittels Schleife aus - jedes Array für sich.
Durch geschicktes Aufteilen in Meldungen ohne Begleittexte und welche mit, lässt sich die Sache mit den Textlisten recht elegant lösen - ein bisschen Planung und Tests sind aber erforderlich.

Falls man später auf irgendein Bit/Bool-basiertes Fehlersystem gehen will, liegen die Fehlerinformationen in Bool-Form vor und müssen nur gepackt oder umformatiert werden - diesen Rechenaufwand schluckt jede S7-1500 locker weg.

lg

 

[Howard]

Moin!

Im Vergleich zum reinen Bitmeldeverfahren hast du bei sehr vielen Meldungen einen Performanceverlust, der im einstelligen Prozentbereich liegt. Die Vorteile liegen aber auf der Hand. Vor allem wenn an der CPU der Webserver aktiv ist, bekommst du deine Fehlermeldungen schon ohne Visu am Webserver angezeigt.

@maxder2te: Magst du das mit dem einstelligen Prozentbereich und "vielen" Meldungen nochmal spezifizieren? Meine Tests damit waren leider eher ernüchternd. Also was die Funktion ansich angeht bin ich voll bei euch - echt ganz gut gelungen. Aber die Performance für eine einzige Meldung ist schon happig. Ich hab meine Zahlen und die Hardware des Testaufbaus leider nicht mehr zur Hand (ich glaub es waren 500 Meldungen), aber ich meine hier gab es eine deutlich größere Einbuße als 1-9%

 

[al3x]

Was für mich derzeit das größte Problem darstellt ist das es wohl keine Möglichkeit gibt die Anzeigeklasse dynamisch zu übergeben. (Hab dazu schon ein Thema eröffnet)
Mit einem HMI-Panel auch kein Problem. Aber wenn mehrere HMI an der Anlage hängen und bestimmte Meldungen nur auf bestimmten Panels angezeigt werden sollen wirds schwierig. Wie löst ihr das?

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin!
@maxder2te: Magst du das mit dem einstelligen Prozentbereich und "vielen" Meldungen nochmal spezifizieren? Meine Tests damit waren leider eher ernüchternd. Also was die Funktion ansich angeht bin ich voll bei euch - echt ganz gut gelungen. Aber die Performance für eine einzige Meldung ist schon happig. Ich hab meine Zahlen und die Hardware des Testaufbaus leider nicht mehr zur Hand (ich glaub es waren 500 Meldungen), aber ich meine hier gab es eine deutlich größere Einbuße als 1-9%

Genau spezifizieren kann ich es nicht, am meisten gebracht hat folgender Trick, der jedenfalls gut funktioniert. Inwieweit das von Siemens so vorgesehen ist, kann ich aber nicht sagen:

FOR #i := 1 TO "nAlarmsGeneral" DO
    IF ("alarmsDb".general[#i] OR #AlarmGeneral[#i].SIG) THEN
        #AlarmGeneral[#i](SIG:="alarmsDb".general[#i]);
    END_IF;
END_FOR;

#AlarmGeneral[#i] ist definiert als ARRAY [1.."nAlarmsGeneral"] OF ProgramAlarm

Mit dieser Variante werden die jeweiligen ProgramAlarm-Instanzen nur bearbeitet, wenn der Alarm ansteht + 1 Zyklus - es hat sich herausgestellt dass die Alarme zuverlässig ihre Kommt- und Geht-Ereignisse auslösen. Und generell haben wir akzeptiert, dass die 1500er-CPUs bis zur Baugröße 1516 ziemlich lahme Krücken sind.

 

[MFreiberger]

Moin al3x,

warum willst Du die Klasse (Meldeklasse) dynamisch übergeben?
Wenn Du dann Meldeklassen anlegst (z.B. "Bereich_1", "Bereich_2", etc.) dann kannst Du doch auf dem Panel auswählen welche Bereiche alle angezeigt werden sollen.
Wenn Du auf dem Panel dann die Meldebereiche auswählen willst, dann projektierst Du eine Meldeanzeige für Bereich 1 und z.B. eine Meldeanzeige für Bereich 1 + Bereich 2.
Dann die jeweilige Meldeanzeige sichtbar machen. So kann der Bediener zwischen allen Meldungen und den Meldungen für einen Bereich umschalten .

VG

MFreiberger

 

[al3x]

Ich möchte aber die Störung als ProgramAlarm direkt im Standardbaustein programmieren.
Der Standardbaustein wird in Bereich 1 und Bereich 2 aufgerufen. Intern im Standardbaustein beim ProgramAlarm Baustein ist aber z.B. fest Anzeigeklasse 1 zugeordnet.
Laut Siemens Support soll ich zwei Aufrufe des ProgramAlarms Projektieren und über eine Variable umschalten :roll:

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

FOR #i := 1 TO "nAlarmsGeneral" DO
    IF ("alarmsDb".general[#i] OR #AlarmGeneral[#i].SIG) THEN
        #AlarmGeneral[#i](SIG:="alarmsDb".general[#i]);
    END_IF;
END_FOR;

#AlarmGeneral[#i] ist definiert als ARRAY [1.."nAlarmsGeneral"] OF ProgramAlarm

Mit dieser Variante werden die jeweiligen ProgramAlarm-Instanzen nur bearbeitet, wenn der Alarm ansteht + 1 Zyklus - es hat sich herausgestellt dass die Alarme zuverlässig ihre Kommt- und Geht-Ereignisse auslösen. Und generell haben wir akzeptiert, dass die 1500er-CPUs bis zur Baugröße 1516 ziemlich lahme Krücken sind.

Puh, das riecht aber nach S5-Style. Erst werden von irgendwoher Daten in ein Stör-Array geschrieben, das Array einzeln beschriftet und dann Durchgriff auf die Instanzdaten (SIG) eines FBs um dann anschließend ProgramAlarm anzuflanschen.
Meiner Meinung nach verschenkst du sehr viele elegante Möglichkeiten die mit ProgramAlarm möglich sind, wenn man damit objektorientiert arbeitet. Aber das ist vielleicht nicht in jeder Branche so einfach möglich.

Bei dem bedingten Aufruf von ProgramAlarm würde ich mal das Verhalten bei SPS-Neuanlauf prüfen. Bei den Alarm8 der S7-400 mache ich den Aufruf auch bedingt, aber zusätzlich einmal bei SPS Neuanlauf im OB100.

 

[Draco Malfoy]

Puh, das riecht aber nach S5-Style. Erst werden von irgendwoher Daten in ein Stör-Array geschrieben, das Array einzeln beschriftet und dann Durchgriff auf die Instanzdaten (SIG) eines FBs um dann anschließend ProgramAlarm anzuflanschen. Meiner Meinung nach verschenkst du sehr viele elegante Möglichkeiten die mit ProgramAlarm möglich sind, wenn man damit objektorientiert arbeitet. Aber das ist vielleicht nicht in jeder Branche so einfach möglich. Bei dem bedingten Aufruf von ProgramAlarm würde ich mal das Verhalten bei SPS-Neuanlauf prüfen. Bei den Alarm8 der S7-400 mache ich den Aufruf auch bedingt, aber zusätzlich einmal bei SPS Neuanlauf im OB100.

Sein Problem ist, daß der vereehrte Kollege, nebst der Ablehnung von Graph aus Gründen der Firmenphilosophie, offensichtlich auch nicht immer, oder nach Möglichkeit wahrscheinlich auch gar nicht, Siemens-Visualisierungen verwenden möchte. Da es aber bei Nichtsiemens Visus wie "Phönix zwei plus minus sinus kosinus", InTouch etc. weder vernünftige Meldungsgenerierung, noch Möglichkeiten zur Anbindung von Instanzen und FacePlates, noch irgendwelche andere Datentypen wie INT, BOOL und REAL gibt, müssen die verehrten Kollegen gezwungenermaßen im S5 Style arbeiten.

Es ist irgendwie bezeichnend, daß es immer wieder dieselbe Personengruppe ist, die regelmäßig mit umreißenden eigenentwickelten Automatisierungskonzepten um die Ecke kommt, Siemens-Panels ablehnt und verteufelt, und gleichzeitig aber selber im S5-Style wie 1982 programmiert. Zu dem umreißenden Automatisierungskonzept gehören in der Regel noch zahlreiche in C oder C++ eigengeschriebene Tools, die angeblich bei der Arbeit mit "völlig unzulänglichem Siemens-Shit" helfen sollen, sowie seltsame Excel-Tabellen mit Telefonbuch von Makros dahinter, um daraus etwa Datenbausteine zu generieren, und möglichst viel unterschiedliche bunte Hardware, die in etwa so zusammenpasst wie Ostereier und Glühwein. Alles zusammen wird dann anschließend als sehr fundierte und durchdachte Vorgehensweise verkauft.

Geschenkt, daß Hersteller darum bemüht sind, ein ganzheitliches Automatisierungskonzept aus einer Hand anzubieten, wo einzelne Komponenten miteinander interagieren, und sich gegenseitig ergänzen. Stattdessen nimmt man Fremdkomponten von seltsamsten Random-Firmen, und beschwert sich darüber daß diese nicht vernünftig mit einer 1516 CPU zusammenarbeiten wollen.

 

[Thomas_v2.1]

Dass auch mal eine Fremdvisualisierung zum Einsatz kommt lässt sich nicht immer vermeiden, wenn der Kunde das so haben will dann bekommt er es auch.
Ich versuche bei meinen Projekten immer objektorientiert zu arbeiten, d.h. Motor, Ventil, Messung, Schieber, Meldebaustein usw. Und dieses Objekt beinhaltet ProgramAlarm oder gibt seinen Status zusätzlich als Word Variable aus um damit optional ein anderweitiges Meldesystem anzutriggern. Damit lassen die die ProgramAlarm-Texte größtenteils automatisch erzeugen. Neues Motor-Objekt einfügen, alles fix und fertig mit allem was dazugehört. Wenn ich das mit dem Array sehe wird mir ganz schwindelig wie viel Arbeit das ist da etwas nachzutragen, ganz zu schweigen dass mir so eine Struktur überhaupt nicht gefällt.
Aber: Es ist alles Geschmackssache, sagte der Affe und biss in die Seife...

 

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich das mit dem Array sehe wird mir ganz schwindelig wie viel Arbeit das ist da etwas nachzutragen, ganz zu schweigen dass mir so eine Struktur überhaupt nicht gefällt.
Aber: Es ist alles Geschmackssache, sagte der Affe und biss in die Seife...

Das deckt sich auch mit dem, was der genannte Kollege ansonsten auch an anderen Stellen hier über die Vorgehensweisen in seiner Firma so geäußert hat. Effizienz scheint dort irgenwie nicht so das Gebot der Stunde zu sein.

Ich habe, allerdings, so ganz grundsätzlich irgenwie nicht so richtig Ahnung, wie man eine Software, die auf Instanzen und Faceplates sowie bausteinbezogenen Meldungen aufbaut, zum Beispiel mit InTouch verheiraten könnte. Soweit ich weiß kennt InTouch keine FacePlates? Folglich wird das in jedem Fall häßlich und umständlich.

Was deine Bausteine angeht: könnte man da beispielsweise den Fehlercode nutzen, um daraus im InTouch über "Analogalarm mit Textliste", wenn es dort soetwas gibt, Meldungen zu generieren ?

 

[SPSSchlumpf]

Hi,

erstmal vielen Dank für die Antworten. Die Performance ist leider ein Problem. An einer 1516-3F hängen:
1x tp1500 comfort
1x wincc advanced mit 2048 powertags
4x wincc advanced mit 128 powertags (reine Anzeigen von ein paar Werten)
12 RFID Lesegeräte
10-12 ET200s mit insgesamt ca. 500 EAs
2 Buskoppler für Fremdgewerke
und über 30 Antriebe die über je 6 E/A Worte angesprochen werden.
Alles über Profinet...

Zykluszeiten dürfen nicht über 25 ms sein.

Ich habe leider keine Erfahrungen mit der 1500er. Hat jemand Erfahung mit einer solchen Menge an Devices und den sich ergebenden Zykluszeiten?

Wir hier schon angesprochen wurde, programmiere ich auch eher aus Sicht auf Objekte. D.h. es wird später ca. 8 verschiedene Standardfbs geben, die ich dann mit den entspechenden EAs verschalte.
Um indirekte Adressierung und multiplexen im HMI zu vermeiden, weil das ja absolute Adressierung vorraussetzt (Stichwort optimierte DBs), setze ich auf Bildbausteine, an die eine Stuktur übergeben wird, in der die Signale gesammelt übergeben werden.
Hier frage ich mich, ob es "zulässig" wäre auf die Struktur direkt in den Instanzen der Objekte (Ventile, Motoren etc.) zuzugreifen. Würde viel Performance sparen, weil ich keine Bereiche an Bausteine übergeben müsste, sondern Sollwerte, Istwerde, Steuer und Statusbits aus dem HMI direkt in die Instanz schreibe/lese... Wobei ich dazu tendiere, wenigstens die Sollwerte zu übergeben, damit bei einem Initialisieren der Instanz diese Werte bleiben.

Was meint ihr?

 

[Onkel Dagobert]

.. Geschenkt, daß Hersteller darum bemüht sind, ein ganzheitliches Automatisierungskonzept aus einer Hand anzubieten, wo einzelne Komponenten miteinander interagieren, und sich gegenseitig ergänzen..

Schade nur dass die Basic-Panels einem hierbei den ganzen Spaß verderben. Wenn Siemens bei den Kleinen das Mengengerüst einschränken würde anstatt den Funktionsumfang, wäre es ok. Was nützt mir denn das tollste Konzept, wenn ich es in nur in zehn Prozent meiner Projekte nutzen kann? Das betrifft nicht nur das Meldekonzept, sondern auch Wertebereiche von Balkenanzeigen, Bildbausteine und vieles andere.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin al3x,

du könntest in Deinem Standardbaustein unter Static ja ein Array[1..4] of Program_Alarm anlegen. Dann dem Standardbaustein als IN ein INDEX für den Program_Alarm übergeben (Aufruf in Bereich 1 ==> INDEX 1; Aufruf in Bereich 2 ==> INDEX 2; usw.).
Für den Meldetext verwendest Du dann eine Textliste. Für den Textlisten INDEX benötigst Du eine WORD-Variable.

In den Meldungen kannst Du dann Meldeklassen für die Meldungen vergeben:
Meldung[1] ==> Meldeklasse 1
Meldung[2] ==> Meldeklasse 2
Meldung[3] ==> Meldeklasse 3
Meldung[4] ==> Meldeklasse 4

Und im Meldetext: @1%t#<Textliste>@

1% = Begleitwert 1 (WORD-Variable)

Textliste:
1: NotHalt-Taster betätigt
2: Zugangstür offen
3: Motorschutzschalter 23 ausgelöst
...


VG

MFreiberger

 

[ADS_0x1]

Ich klinke mich mal hier ein, derzeitig arbeite ich auch mit dem ProgramAlarm Bausteinen, das grundlegende Verhalten habe ich (glaube ich ) verstanden, zu dieser Diskussion hier eine Frage:

Kann ich die ID einer Meldung ebenfalls beeinflussen?

Sobald ich einen ProgramAlarm verwende, wird unter PLC-Überwachungen & -Meldungen unter dem Reiter Meldungen und dann Programmmeldungen ein Eintrag erstellt, in dem ich die Einstellungen nochmal adaptieren kann. Hier kann ich auch über @Begleitwert und t#Textliste dynamisch reagieren.
Jetzt haben wir allerdings Störmeldelisten (yippie, - na klar, in Excel), bei denen jeder Störmeldung eine einzigartige ID zugeordnet ist - diese ID identifiziert die Meldung auch in übergeordneten System (bspw. sollen wir diese von WinCC an einen OPC Server senden, bei der Meldungen von allen angebunden Anlagen in dem Bereich auflaufen). Spanne ich den Bogen zu meiner Frage zurück: Muss diese ID nun als eigener Begleitwert (und damit Text) mit übergeben werden oder kann ich auch die integrierte Melde-ID-Verwaltung dazu nutzen?

Viele Grüße!

 

[MFreiberger]

Moin ADS_0x1,

das verstehe ich nicht ganz:
Kann ich denn anhand der ID festlegen, ob diese Meldung auf einem z.B. Comfort-Panel angezeigt wird? Ich dachte diese Auswahl habe ich nur über die Meldeklassen?
Ich glaube allerdings nicht, dass man die Melde-ID als Begleitwert übergeben kann. Die ID vergibt die TIA-Datenbank doch selber und automatisch?

VG

MFreiberger

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sein Problem ist, daß der vereehrte Kollege, nebst der Ablehnung von Graph aus Gründen der Firmenphilosophie, offensichtlich auch nicht immer, oder nach Möglichkeit wahrscheinlich auch gar nicht, Siemens-Visualisierungen verwenden möchte. Da es aber bei Nichtsiemens Visus wie "Phönix zwei plus minus sinus kosinus", InTouch etc. weder vernünftige Meldungsgenerierung, noch Möglichkeiten zur Anbindung von Instanzen und FacePlates, noch irgendwelche andere Datentypen wie INT, BOOL und REAL gibt, müssen die verehrten Kollegen gezwungenermaßen im S5 Style arbeiten.

Es ist irgendwie bezeichnend, daß es immer wieder dieselbe Personengruppe ist, die regelmäßig mit umreißenden eigenentwickelten Automatisierungskonzepten um die Ecke kommt, Siemens-Panels ablehnt und verteufelt, und gleichzeitig aber selber im S5-Style wie 1982 programmiert. Zu dem umreißenden Automatisierungskonzept gehören in der Regel noch zahlreiche in C oder C++ eigengeschriebene Tools, die angeblich bei der Arbeit mit "völlig unzulänglichem Siemens-Shit" helfen sollen, sowie seltsame Excel-Tabellen mit Telefonbuch von Makros dahinter, um daraus etwa Datenbausteine zu generieren, und möglichst viel unterschiedliche bunte Hardware, die in etwa so zusammenpasst wie Ostereier und Glühwein. Alles zusammen wird dann anschließend als sehr fundierte und durchdachte Vorgehensweise verkauft.

Geschenkt, daß Hersteller darum bemüht sind, ein ganzheitliches Automatisierungskonzept aus einer Hand anzubieten, wo einzelne Komponenten miteinander interagieren, und sich gegenseitig ergänzen. Stattdessen nimmt man Fremdkomponten von seltsamsten Random-Firmen, und beschwert sich darüber daß diese nicht vernünftig mit einer 1516 CPU zusammenarbeiten wollen.

Vielen herzlichen Dank für deine Ausführungen. Ich gewinne immer mehr den Eindruck, dass du ein Skript benutzt, welches aus verschiedenen Wörtern (Sinus, Kosinus, plus, minus, Excel, Telefonbuch, C, bunt, ...) Random-Standardsätze zusammenbaut, und dann 80% des Eintrags ergeben. Der Rest setzt sich zusammen aus purem Hass, Ignoranz und aus dem Zusammenhang gerissenen Zitaten.

 

[dentech]

Bitte bleibt mal sachlich. Wir nutzen auch den Program Alarm und ich finde sehr gut, dass der Program Alarm sehr schön instanziert werden kann. Du brauchst z.B. für Ventile nur einen Baustein anlegen, wir machen dann sehr viel über Textlisten. Dann brauchst du für z.B. 10 Ventile den Baustein nur 10x aufrufen und um die Störmeldungen kümmert sich der Baustein selber.

 

[ADS_0x1]

Kann ich denn anhand der ID festlegen, ob diese Meldung auf einem z.B. Comfort-Panel angezeigt wird? Ich dachte diese Auswahl habe ich nur über die Meldeklassen?
Ich glaube allerdings nicht, dass man die Melde-ID als Begleitwert übergeben kann. Die ID vergibt die TIA-Datenbank doch selber und automatisch?

Ja richtig, das ist genau das, worauf ich hinaus möchte: Kann man die ID auch NICHT automatisch vergeben lassen, da diese für uns wichtig ist.

Die Alarmgruppe / Meldungsgruppe, sowie Prioritäten kann ich ja individuell konfigurieren und habe so eine Zuordnung. Meine Frage zielt jetzt explizit auf die IDs ab. Sorry für die ungenaue Fragestellung. Mir geht es ja auch nicht um Filterung / Auswahl an einem Panel / in WinCC, sondern über die Weiterverarbeitung und Dokumentation.