TIA Bit-Melde-System, Program_Alarm, ProDiag, … ?

Chräshe

Level-3
Beiträge
1.220
Reaktionspunkte
613
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

wie ist bei euch das Meldesystem in der Praxis aufgebaut?

Mich interessiert insbesondere:
  • Wie werden Störungen in der SPS generiert? (Bitmeldungen, Program_Alarm, ProDiag, …)
  • Wo erfolgt die Auswertung? (SPS vs. HMI / SCADA)
  • Welche Systeme haben sich bewährt?
Speziell würde mich interessieren:
  • Wer ist vom klassischen Bitmeldesystem auf Program_Alarm umgestiegen?
  • Wie sind eure Erfahrungen damit?
  • Ist jemand wieder zurückgegangen – und wenn ja, warum?
Danke vorab für eure Rückmeldungen!

Gruß
Chräshe
 
Ich setze jetzt auf Programalarm.
Bei die einfache Steuerungen mit Flex und Advanced sind wir dann von Bitmeldung auf Programalarm gegangen.
Die mit echte WinCC hatten schon immer alarm8P
Ich habe lauter gute Erfahrungen damit. Naja 1 Ausnahme, die mehrsprachigkeit ist nicht so toll.
Das ist bei mehrfach verwendete FB's ein Thema.

Jetzige system
1500er mit WinCC 8.1 Programalarm
1500er mit WinCC Unified Programalarm
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur programalarm. Seit ich damals nach zehn jahren programmier- abstinenz zurückgekommen bin und mit tia 15.1 einstieg, war das für mich die effektifste methode. Auch zwecks mehrsprachigkeit.
Ich hab mal aushilfsweise für ein partnerunternehmen bei einem stressigen projekt ausgeholfen und da tage nur mit dem bitmeldeverfahren verbracht.
Also nir texte und adressen eintragen. Cooy paste aus irgendwelchen excel vorlagen.
Ich wollt nix sagen, da die firma auf das gesetzt hat.
Aber naja…
 
Wenn wir unseren internen Standard einsetzen ProDiag, aber meisten schreiben die Kunden (Automobil) eh was vor. Am besten gefällt mir ProgramAlarm. Mehrsprachigkeit und Einbindung sind super wenn mal verstanden hat wies geht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wenn die Software gut und passend strukturiert ist, funktioniert das mit allen Meldeverfahten gut. Muss halt zum restlichen Programmierstil passen.

Nachteil von Alarm_DQ Alarm8P Programmalarm war immer die begrenzte Anzahl gleichzeitig anstehender Meldungen...
Und man ist halt auf Siemens beschränkt. Fremdhersteller wird schwierig, oder HMI nicht im selben Projekt wie SPS. Oder paralleles Arbeiten von mehreren Kollegen an HMI und SPS.

Also ich seh da pauschal keinen Vorteil bei dem einen oder anderen System...

Schlechten Stil kann man mit jedem System fabrizieren. Wichtig wie immer, ein fremder Programmierer sollte intuitiv damit klarkommen.
 
Ich hab mal aushilfsweise für ein partnerunternehmen bei einem stressigen projekt ausgeholfen und da tage nur mit dem bitmeldeverfahren verbracht.
Also nir texte und adressen eintragen. Cooy paste aus irgendwelchen excel vorlagen.
ich kenn das auch, die Meldungen sind wirr im Programm verstreut, werden irgendwie in Worte zusammenkopiert und mann sucht sich dämlich.
Geht aber auch anders. Du hast einen definierten MeldeDB, der wird an einer Stelle im Programm mit den Meldungen versorgt. Und in Excel überlegt man sich, bevor man zu programmieren anfängt, welche Meldenummer/bereiche man für welche Anlagenteile, Feldgeräte hernehmen will... Oder alternativ ein Word pro Feldgerät...
Aber ja 🤷
Vermutlich sah bei Dir der Rest der Software auch nicht besser strukturiert aus?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für die Programmierung ist Programm Alarm bestimmt von Vorteil wenn man einen FB oft im Program verwendet, für einen Instanthalter der das Program.vielleicht nur zum Teil oder gar nicht kennt ist das Bitmeldeverfahren leichter zum nachvollziehen da dies ja schon lange bei Siemens und vielen anderen Herstellern in ähnlicher Weise verwendet wird
 
Bitmeldeverfahren

Ich habe dafür je Aggregat einen eigen Baustein in dem nur die Meldungen auf die Bits geschupst werden. Die Fehlermeldungen liegen als Exceldatei vor und werden in HMI-Projekt kopiert. Dann ist auch eine neue Fremdsprache schnell hinzugefügt.

Was mich dabei etwas nervt ist das einfügen von Variablen in den Meldetest. Das ist saudumm gelöst. Felder zu klein usw. Das habe ich zum Glück nur bei einigen wenigen Meldungen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wobei ich jetzt die Idee des Programm Alarms im Grunde echt gut finde.

Ich hatte letztens einen Kunden-Standard in den Fingern, da wurde ein OPC-Export gemacht. Die XML wurde dann durch ein externes Programm gejagt, wass dann unter anderem die Meldungen fürs HMI generiert hat.
 
Ich bin bisher beim Bit-Meldesystem geblieben, da ich überwiegend ältere Anlagen mit S7-300 betreue.
Dort setze ich bereits Bausteine ein, in denen die Fehlerauswertung integriert ist.

Zusätzlich gibt es einen separaten Baustein, der unabhängig davon Meldungen bzw. Störungen generiert.
Das System ist insgesamt recht strukturiert aufgebaut.

Was mich jedoch nach wie vor stört:
Die Meldetexte müssen an einer anderen Stelle gepflegt werden als die eigentliche Meldelogik.

Wie findet man bei einer Program_Alarm-Meldung im HMI wieder die konkrete Stelle im SPS-Programm, die die Störung ausgelöst hat?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie findet man bei einer Program_Alarm-Meldung im HMI wieder die konkrete Stelle im SPS-Programm, die die Störung ausgelöst hat?
Das ist tatsächlich schwierig.

Bei Alarm8P war es die Instanzbausteinname die du nachvollziehen konntest.
Das gibt es bei ProgramAlarm auch, aber nur wenn du dies so projektiertst. Mit "Schlüsselworte"
 
Ich denke, die meisten hier meinen mit Meldesystem Steuerungs-/Anlageninterne Störungen.

Ich bin gerade dabei unser Werks-weites Meldesystem aus den 80ern in die Neuzeit zu bringen. Aktuell haben wir überall im Werk alte S5'en verteilt, die per Hardware-IO Bits einsammeln, die dann an eine zentrale Melde-SPS gegeben werden. (Meist noch über L1-Bus über einen Uralt-L1->TCP/IP-Konverter in eine 400er.) Die SPS wertet dann nach Prio aus und dann werden bei uns Störungen nacheinander auf einen DAKS gegeben. Alles über einzelne Bits. Ich habe die letzten Monate damit verbracht diese ganzen Meldungen in der S7 auf zentrale Melde-DBs zu bringen. Vorher war alles wild verstreut. Viele Bits im Programm konnten nicht zugeordnet werden. Dies musste ich rückwärts bis über den Bus in die meldende SPS verfolgen und teilweise Kabel nachzuppeln bis ich den Kontakt nachvollziehen konnte. (Tja, wenn die Doku sch... ist!) Inzwischen konnte ich 99.8% zuordnen und dokumentieren.

Viele Meldungen im Werk werden inzwischen durch das vor einigen Jahren erneuerte Leitsystem erzeugt und dann per IO auf eine der S5'en gegeben. Dies will ich demnächst durch eine Anbindung per OPC ersetzen. (Ich will die S5'en und den L1-Bus los werden!) Die Anbindung per OPC ans Leitsystem soll dann bidirektional laufen. So sollen z.B. Serverraum-Alarme über OPC auch rückwärts dem Leitsystem gemeldet werden, gleichzeitig aber auch über die Telefonanlage an das zuständige Personal gemeldet werden.

Da Änderungen in Leitsystem oft mit hohen externen Kosten verbunden sind, sollen Meldungen weiterhin durch ein paralleles System mittels SPS'en erfolgen. (Alles was für die Bediener/Operator im Leitsystem relevant ist, bleibt im Leitsystem.) Wir haben viele "Kontakte", die nicht aufs Leitsystem gehen. Gleichzeitig sollen viele Zustände des Leitsystems am OPC verfügbar sein, sodass wir mit kleinen Änderungen in der SPS schnell weitere Meldungen generieren können.

Unser Meldesystem ist an die Brandmeldetechnik und zusätzlich zum Leitsystem auch an die Gebäudeleittechnik angebunden. Über das Meldesystem laufen entsprechend intern auch die Alarmierungen für Feuer (Sirenenansteuerung parallel zur Brandmeldeanlage), Unfall (interne Alarmierung der Ersthelfer) und andere "Zwischenfälle". Es wird das Druckluft- und Dampfsystem, sowie andere Energieerzeuger überwacht.

Unser Meldesystem ist also mehr für große Störungen (Stromaufall in Teilen des Werkes, Störungen der Kompressoren), als für kleine Fehlermeldungen wie "Motschu 12Q22 gefallen".

Bei abgeschlossenen Maschinen haben wir jenach Hersteller oft verschiedene Varianten, wie Meldungen verarbeitet werden. Ich finde ja MeldeDBs oder zentrale Meldebausteine ganz gut, da man da oft nachvollziehen kann, was die Anlage hat. Ein gesetztes Bit lässt sich leichter nachvollziehen, als eine gedropte Meldung auf einem HMI. Oft haben wir es, die Anlage steht und rührt sich nicht mehr und man erkennt nicht, warum. Leider neigen viele Programmierer dazu, Sammelmeldungen zu generieren, die dem Anlagenpersonal nicht weiter helfen. Da hilft uns oft nur das PG. (Meldetexte wie "weil das so ist" hilft nicht weiter! Okay, Text lautete: "Aufgrund eines eingelaufenen Ereignisses wurde der Maschinenzyklus gestoppt.")

Ich nutze bei neueren Anlagen, die eine 1200 oder 1500 hat meist beides. Ich setze bei der Fehlererkennung ein Bit in einem Meldebaustein und gleichzeitig einen Programm_Alarm fürs HMI absetze. Quasi mehrere "Systeme" nutze. Setze das Fehlerbit und dann gleichzeitig auf dem HMI den Fehler mit Begleitwerten (z.B. Maschinenposition bei Fehler. Da kann man dann erkennen, ob z.B. ein Sensor zu spät/früh oder falsche Werte liefert.)

MfG
 
Lässt sich den die Zykluszeit bei Verwendung von Programm Alarm reduzieren?
Ich bin bisschen am grübeln, ob ich eher auf das bitmrlde erfahren oder Programm Alarm setzen sollte.
Programm Alarm hätte den Charm, dass ich das in jedem Aktor Baustein selbst händeln könnte. Dan würde das Mappen der Trigger & bitmeldungen entfallen. Sehe ich das richtig?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Problem ist ja, dass das mit der Komplexität der Meldung und der Anzahl der Alarme steigt. Daher, setze ich dies nur bei bestimmten Situationen und oftmals eben durch einen gespeicherten Alarm ein. Das bedeutet um die Zykluszeit im kritischen Moment nicht zu belasten, versuche ich den Alarmzeitpunkt eben nicht direkt mit dem Event zu verknüpfen. Bei einigen Alarmen lässt sich das nicht ändern, aber da sollte man sparsam sein. (Wenn in der Millisekunde relevante Parameter mit gegeben werden.)

Wenn kurze Zykluszeit wichtig ist, sollte man Programmalarme nicht für jeden Zweck nutzen. Da gehen einige "ms" für drauf. Das kann bei Maschinen, wo es um Millimetergenaue Positionierung geht schon nachteilig sein. Da ist es entscheidend ob die Zykluszeit 2ms oder 10ms beträgt.

MfG
 
Wenn kurze Zykluszeit wichtig ist, sollte man Programmalarme nicht für jeden Zweck nutzen. Da gehen einige "ms" für drauf. Das kann bei Maschinen, wo es um Millimetergenaue Positionierung geht schon nachteilig sein. Da ist es entscheidend ob die Zykluszeit 2ms oder 10ms beträgt.
Dann hat mann doch das falsche verfahren. Also nicht ein Programm mit "OB1" aber mit eine Technologiebaugruppe arbeiten
 
Lässt sich den die Zykluszeit bei Verwendung von Programm Alarm reduzieren?
Ich bin bisschen am grübeln, ob ich eher auf das bitmrlde erfahren oder Programm Alarm setzen sollte.
Programm Alarm hätte den Charm, dass ich das in jedem Aktor Baustein selbst händeln könnte. Dan würde das Mappen der Trigger & bitmeldungen entfallen. Sehe ich das richtig?
Lässt sich reduzieren in dem du nicht benutzte Alarme deaktivierst/ überspringst.

z.b. Analogwerverarbeitung, Single Channel jeweils 8 Alarme
HHH, HH, H L, LL, LLL Overflow, Unterflow
bei nicht verwendete Grenzwerten bleiben nur 2 alarme überig. rest wird nicht bearbeitet.
 
Zurück
Oben