- Beiträge
- 3.470
- Reaktionspunkte
- 1.318
-> Hier kostenlos registrieren
Was hier noch nicht erwähnt ist;
ProgramAlarm ist Zeitfolgerichtig.
Bitmeldung nicht
ProgramAlarm ist Zeitfolgerichtig.
Bitmeldung nicht
TIA Bit-Melde-System, Program_Alarm, ProDiag, … ?
- Ersteller Chräshe
- Erstellt am
-> Hier kostenlos registrieren
Stups
Level-2
- Beiträge
- 185
- Reaktionspunkte
- 77
Ich habe nichts vorgeschlagen, da sie die anderen varianten ja bereits kannten.
Zum missionieren von alteingesessenen programmierern mit fixer meinung ist mir die zeit zu schade.
Und da ich nach stunden abgerechnet habe, …
Stups
Level-2
- Beiträge
- 185
- Reaktionspunkte
- 77
-> Hier kostenlos registrieren
Doch- war ganz sauber.
War trotzdem stupides, stundenlanges copy paste, das mit dem programalarm nicht nötig gewesen wäre.
Stups
Level-2
- Beiträge
- 185
- Reaktionspunkte
- 77
Über die alarm- id. Die ist eindeutig.
Stups
Level-2
- Beiträge
- 185
- Reaktionspunkte
- 77
Da ist der main cycle sowieso der falsche ort für sowas. Und auch die verwendete technologie wahrscheinlich.
- Beiträge
- 3.470
- Reaktionspunkte
- 1.318
-> Hier kostenlos registrieren
Und dann händisch suchen im Übersicht der Meldungen? (Seitens SPS)
Oder hast du etwas praktischer?
Und mann muss die ID im Meldezeile einblenden
Stups
Level-2
- Beiträge
- 185
- Reaktionspunkte
- 77
Ja natürlich. Wird dann eh der querverweis angezeigt.
Geht das beim bitmeldeverfahren einfacher?
Id muss man nicht unbedingt einblenden.
Sieht man eh in der tia meldeanzeige auch.
Ich hatte in meiner karriere bis jetzt auch nur einmal den fall, dass ich die herkunft einer meldung suchen musste. Da hat eine fremde sps auf holländisch (tatsache
) eine meldung geschmissen und da war natürlich kein text hinterlegt.
- Beiträge
- 3.470
- Reaktionspunkte
- 1.318
Wenn z.b. der MeldeDB die Meldenummer enthält ist es einfach.
Ich war nicht SchuldIch hatte in meiner karriere bis jetzt auch nur einmal den fall, dass ich die herkunft einer meldung suchen musste. Da hat eine fremde sps auf holländisch (tatsache
- Beiträge
- 1.182
- Reaktionspunkte
- 595
-> Hier kostenlos registrieren
Ich sehe das ähnlich wie @ducati in #6.
Du kannst mir jedem System gut oder schlecht programmieren, wobei gut/schlecht oft ein Thema der Perspektive oder der Anforderungen ist.
Ich persönlich hab zwar mal versucht per Programm Alarm ein Meldesystem aufzuziehen, bin damit aber böse auf die Schnauze geflogen.
Wie haben zuviele Bestands-Systeme + nicht Siemens Software, die alle Bitmelde-System erwarten.
Dementsprechend bin ich zwangsverheiratet mit dem klassischen Bitmelde-System.
Wird alles zentral in einem FB gesammelt & darüber auch Gruppen- bzw. Aggregat-bezogen ausgewertet.
Grade für Diagnosen mit ausländischen Kunden ist das ganz praktisch, da ich über die Meldenummer sofort den Querverweis bekomme was oder welche Instanz von was die Meldung wirft.
Da fand ich Programm Alarm / Pro diag immer etwas....unkomfortabel.
Ganz abgesehen vom Lizenz-Thema bei Pro-Diag. Allein der Fakt, dass hier eine Runtime-Lizenz benötigt wird ist aus internen Gründen bei uns ein Show-Stopper.
Was ich letztens noch als weitere Option gesehen habe, war die Weitergabe von Meldungen per SysLog-Message.
Ging damit aber "nur" an ein Scada-System.
Die Meldungen zum HMI waren wieder gewöhnliche Bitmeldungen.
Fand ich ganz interessant umgesetzt....
Du kannst mir jedem System gut oder schlecht programmieren, wobei gut/schlecht oft ein Thema der Perspektive oder der Anforderungen ist.
Ich persönlich hab zwar mal versucht per Programm Alarm ein Meldesystem aufzuziehen, bin damit aber böse auf die Schnauze geflogen.
Wie haben zuviele Bestands-Systeme + nicht Siemens Software, die alle Bitmelde-System erwarten.
Dementsprechend bin ich zwangsverheiratet mit dem klassischen Bitmelde-System.
Wird alles zentral in einem FB gesammelt & darüber auch Gruppen- bzw. Aggregat-bezogen ausgewertet.
Grade für Diagnosen mit ausländischen Kunden ist das ganz praktisch, da ich über die Meldenummer sofort den Querverweis bekomme was oder welche Instanz von was die Meldung wirft.
Da fand ich Programm Alarm / Pro diag immer etwas....unkomfortabel.
Ganz abgesehen vom Lizenz-Thema bei Pro-Diag. Allein der Fakt, dass hier eine Runtime-Lizenz benötigt wird ist aus internen Gründen bei uns ein Show-Stopper.
Was ich letztens noch als weitere Option gesehen habe, war die Weitergabe von Meldungen per SysLog-Message.
Ging damit aber "nur" an ein Scada-System.
Die Meldungen zum HMI waren wieder gewöhnliche Bitmeldungen.
Fand ich ganz interessant umgesetzt....
Also ich verwende im Kern eine Art Bitmeldeverfahren, das sich dann an verschiedenste Mechanismen docken lässt. Die "Bits" sind ein Bool-Array, welches sich schön beschriften lässt. Dazu extistieren 10 Arrays gleicher Länge, 8 mit DINT, 2 mit String, welche die "Begleitwerte" aufnehmen können. Die Begleitwerte werden mit der dem Ereignis "kommt" und "geht" gespeichert (also mit den Flanken der Melde-Bool).
Program-Alarm ist an dieses System immer angedockt, weil es eine einfache Meldeauswertung per Web-Server erlaubt, ohne dass eine Visu existiert (und das ist eher die Regel as die Ausnahme). Die Program-Alarm-Instanzen sind ebenfalls als Array mit der gleichen Länge abgebildet, die 10 möglichen Begleitwerte sind immer mit verschaltet. Das Thema "Zykluszeit" wird durch einen Mechanismus abgefangen, der die eigentlichen ProgramAlarm-Anweisungen nur aufruft, wenn sich was verändert oder zum Initialisieren.
Get_Alarm läuft immer und schiebt die Meldeereignisse per TCP-Stream an einen Logger raus.
Zusätzlich ist ein System angebunden, welches einen Teil der Meldungen per Profinet als Bits erhält und damit was anfängt.
In der Vergangenheit waren oftmals auch noch Basic-Panels mit von der Partie, die Meldebits wurden hierfür so umgemappt, dass das Bitmeldeverfahren dieser Panels genutzt werden konnte.
Kommen VoT Apps zum Einsatz werden die Meldungen hierfür aus den Get_Alarm Daten erzeugt, das funktioniert sehr zuverlässig, ist aber recht träge.
Das System ist eher zentral gehalten, wir realisieren hauptsächlich kleine Anwendungen damit, dafür in Großserien.
Program-Alarm ist an dieses System immer angedockt, weil es eine einfache Meldeauswertung per Web-Server erlaubt, ohne dass eine Visu existiert (und das ist eher die Regel as die Ausnahme). Die Program-Alarm-Instanzen sind ebenfalls als Array mit der gleichen Länge abgebildet, die 10 möglichen Begleitwerte sind immer mit verschaltet. Das Thema "Zykluszeit" wird durch einen Mechanismus abgefangen, der die eigentlichen ProgramAlarm-Anweisungen nur aufruft, wenn sich was verändert oder zum Initialisieren.
Get_Alarm läuft immer und schiebt die Meldeereignisse per TCP-Stream an einen Logger raus.
Zusätzlich ist ein System angebunden, welches einen Teil der Meldungen per Profinet als Bits erhält und damit was anfängt.
In der Vergangenheit waren oftmals auch noch Basic-Panels mit von der Partie, die Meldebits wurden hierfür so umgemappt, dass das Bitmeldeverfahren dieser Panels genutzt werden konnte.
Kommen VoT Apps zum Einsatz werden die Meldungen hierfür aus den Get_Alarm Daten erzeugt, das funktioniert sehr zuverlässig, ist aber recht träge.
Das System ist eher zentral gehalten, wir realisieren hauptsächlich kleine Anwendungen damit, dafür in Großserien.
- Beiträge
- 9.521
- Reaktionspunkte
- 2.404
Ich, Bit-meldungen.
Es stammt von alten Zeiten mit S5 und Allen Bradley mit Siemens HMI.
Aber ich sehe eigentlich keinen Grund auf CPU-Meldesystem zu wechseln. Die fundamentale Vorteil wäre die genaue Zeitstempel für jeden Alarm. Dies ist sicherlich einen 'muss haben' für einige, aber nicht in meinem Fall.
Das mit die Vorteilhafte strukturierte Programmierung bei CPU-Meldungen; ich lese in die Beiträge von andere Mitglieder das dies ist nicht ganz unproblematisch.
Ich brauche unbedingt Multi-Sprachen.
Die Alarm tekste werden in einen Excel vorbereitet (und wartet). Es gibt pro Standard FB einen Anzahl Standard Meldungen.
Mit die Standardardisierte mehr-sprachige Texte und Excel Formeln lassen sich relativ Schnell sämtliche Meldetexte generieren.
Dann muss man diese Tekste in TIA importieren. Und jeden Änderung muss in die Excel gemacht werden, und wieder importiert.
Ist ein bisschen lästig, aber nicht soo schlimm.
Für einen Anlage mit ungf. 80 Feldgeräte und ungf. 1000 E/A nimmt es einen halben Tag.
Es stammt von alten Zeiten mit S5 und Allen Bradley mit Siemens HMI.
Aber ich sehe eigentlich keinen Grund auf CPU-Meldesystem zu wechseln. Die fundamentale Vorteil wäre die genaue Zeitstempel für jeden Alarm. Dies ist sicherlich einen 'muss haben' für einige, aber nicht in meinem Fall.
Das mit die Vorteilhafte strukturierte Programmierung bei CPU-Meldungen; ich lese in die Beiträge von andere Mitglieder das dies ist nicht ganz unproblematisch.
Ich brauche unbedingt Multi-Sprachen.
Die Alarm tekste werden in einen Excel vorbereitet (und wartet). Es gibt pro Standard FB einen Anzahl Standard Meldungen.
Mit die Standardardisierte mehr-sprachige Texte und Excel Formeln lassen sich relativ Schnell sämtliche Meldetexte generieren.
Dann muss man diese Tekste in TIA importieren. Und jeden Änderung muss in die Excel gemacht werden, und wieder importiert.
Ist ein bisschen lästig, aber nicht soo schlimm.
Für einen Anlage mit ungf. 80 Feldgeräte und ungf. 1000 E/A nimmt es einen halben Tag.
- Beiträge
- 9.521
- Reaktionspunkte
- 2.404
-> Hier kostenlos registrieren
Oh ja, ich haben vergessen zu erwähnen, dass Heute wird es gefordert dass sämtliche Alarme in die Cloud verlagert werden mussen (imponierend was die Jungs immer erfindet), zusammen mit einen Haufen andere Prozesswerte. Kein Problem, sie lesen einfach denselbe Alarm DB welche ich sowiso für die Bitmeldungen verwendet.
Es helft dass die Zeitgenauichkeit nicht so fein sein muss. 50-100 ms wird erreicht. Wenn es 1 Sekunde wäre, wurde es auch i.O sein.
Es helft dass die Zeitgenauichkeit nicht so fein sein muss. 50-100 ms wird erreicht. Wenn es 1 Sekunde wäre, wurde es auch i.O sein.
MFreiberger
Level-3
- Beiträge
- 3.439
- Reaktionspunkte
- 1.008
Moin,
was bei Steuerungs-Meldungen, die über einen Program_Alarm erzeugt werden noch interessant ist (zumindest für uns), ist, dass diese direkt als OPCUA-Alarm an einen Client gesendet werden.
Dazu ist der Meldetext dann an allen Anzeigen konsistent gleich und Änderungen können zentral an der Steuerung erfolgen ohne, dass ein Partner eine Textliste o.ä. anpassen muss. Das gilt für comfort-Panels bzw. alle Anzeigen von SIEMENS, die die Steuerungs-Meldungen anzeigen und für die OPCUA-Clients.
VG
MFreiberger
was bei Steuerungs-Meldungen, die über einen Program_Alarm erzeugt werden noch interessant ist (zumindest für uns), ist, dass diese direkt als OPCUA-Alarm an einen Client gesendet werden.
Dazu ist der Meldetext dann an allen Anzeigen konsistent gleich und Änderungen können zentral an der Steuerung erfolgen ohne, dass ein Partner eine Textliste o.ä. anpassen muss. Das gilt für comfort-Panels bzw. alle Anzeigen von SIEMENS, die die Steuerungs-Meldungen anzeigen und für die OPCUA-Clients.
VG
MFreiberger
