MFreiberger
Level-3
- Beiträge
- 3.327
- Reaktionspunkte
- 949
-> Hier kostenlos registrieren
Offensichtlich. Denn so funktioniert es bei uns
TIA program_alarm aus 1515
- Ersteller derwestermann
- Erstellt am
-> Hier kostenlos registrieren
Jochen Kühner
Level-3
- Beiträge
- 4.488
- Reaktionspunkte
- 728
Hab ich mich auch schon gefragt, aber was willst du tun. Ich finde es auch voll nervig das man ausenrum programmieren muss. Vorallem springs du wenn du auf den Alarm klickst, erst mal auf den Alarmbaustein der das kapselt (zumindest bei uns). Unschön... aber wahrscheinlich soll ProDiag forciert werden.
- Beiträge
- 6.698
- Reaktionspunkte
- 1.690
-> Hier kostenlos registrieren
So auch, Mario:
Code:
FOR #i := 0 TO msgMaxIndex DO
IF "DB".TRIGGER_aux[#i] OR "DB".TRIGGER[#i] THEN
Program_Alarm[#i](SIG := "DB".TRIGGER[#i] ...) ;
END_IF;
"DB".TRIGGER_aux[#i] := "DB".TRIGGER[#i] ;
END_FOR ;
Code:
FOR #i := 0 TO msgMaxIndex DO
IF "DB".TRIGGER_aux[#i] XOR "DB".TRIGGER[#i] THEN
Program_Alarm[#i](SIG := "DB".TRIGGER[#i] ...) ;
END_IF;
"DB".TRIGGER_aux[#i] := "DB".TRIGGER[#i] ;
END_FOR ;
Code:
FOR #i := 0 TO msgMaxIndex DO
IF "DB".TRIGGER_aux2[#i] XOR "DB".TRIGGER[#i] THEN
Program_Alarm[#i](SIG := "DB".TRIGGER[#i] ...) ;
END_IF;
"DB".TRIGGER_aux2[#i] := "DB".TRIGGER_aux[#i] ;
"DB".TRIGGER_aux[#i] := "DB".TRIGGER[#i] ;
END_FOR ;- Beiträge
- 9.191
- Reaktionspunkte
- 2.950
Was passiert, wenn der Melde-DB verändert und neu geladen wird? Was passiert bei SPS Neustart? Wenn das nicht alle Bedingungen zuverlässig abfängt, dann führt das zu "hängenden" Meldungen, die nur noch wegzubekommen sind wenn man die Ursache noch einmal auslöst. Das Bausteinmeldeverfahren gab es bei den S7-300/400 auch schon, nicht umsonst gab es da in WinCC ein "Not-Quittieren". Beim Alarm_8 verfahren wurde das auch so programmiert wie von dir, aber zusätzlich wurde der meldefähige Baustein auch noch bei SPS-Neuanlauf / Warmstart angestoßen.
Wie habt ihr das gelöst? Kenne das Problem auch - es bleibt ja nur abzufragen wie der Alarm Status ist und das mit der eigenen Logik vergleichen... also zu merken ob der Alarm theoretisch angezeigt werden sollte oder eben nicht.
Zuletzt bearbeitet:
-> Hier kostenlos registrieren
Ich habe da einen FB um den Program_Alarm geschrieben, der mit Get_AlarmState und dem Program_Alarm zusammen den Status abfragt und daraus dann verknüpft den EN-Eingang vom Program_Alarm schaltet.
Die Zykluszeit geht damit deutlich weniger hoch als wenn Program_Alarm dauerhaft enabled ist.
Prüfst du permanent den Status? Ich dachte mir ich mache das nur beim Neustart-SPS oder wenn ich per Button in der VISU einen "Hardreset" der Meldungen durchführe.
Ja, den Status prüfe ich permanent. Daraus schaue ich ob ein Alarm gekommen, gegangen, quittiert, nicht quittiert ist, etc.
Zusätzlich merke ich mir auch den externen AlarmTrigger und verhackstücke diesen mit dem AlarmStatus.
-> Hier kostenlos registrieren
Okay super danke! Das werde ich auch so machen. Habe bisher einen FB "Program_Alarm_Control" vor dem Program_Alarm aufgerufen der den EN und SIG des Program_Alarm schaltet. Dann kommt da jetzt noch der Status rein
- Beiträge
- 5.747
- Reaktionspunkte
- 1.690
Das dürfte genau das sein. Und ja ProDiag ist schon cool Aber es kann halt so viel das man üblicherweise nicht braucht, das man da ruhig die einfache Alarmfunktionalität for free weitergeben könnte.
-> Hier kostenlos registrieren
Moin. Könntest du dein Stück Code mal erklären?
Wenn ich die Program_Alarm getriggert aufrufe, spare ich 30% Zykluszeit. Wenn ich da dann zusätzlich permanent den Status abfrage, dann erhöht sich die Zykluszeit auf meine alte Zykluszeit +30% :-D
Also ich bin deutlich langsamer als vorher. Sicher, dass es schneller geht wenn du diesen permanent aufrufst?
Wie wertest du den Status aus? Kommend/Gehend per SLICE Befehl?
Ich habe den Code gerade nicht zur Hand, das war bei meinem vorherigen Arbeitgeber.
Kann bei Gelegenheit mal nachschauen wie es ungefähr gemacht ist.
Ich habe das bei einem Projekt mit einer 1517F initial gemacht, da war natürlich Power vorhanden.
Es waren geschätzt insgesamt 1500-2000 Instanzen des Bausteins.
Später habe ich das auch auf 1516F und 1512SP laufen gehabt, mit deutlich weniger Instanzen ( ca. 100 bei der 1512SP).
Die Zykluszeiten waren aber alle im Rahmen, sodass es für unsere Anlagen damit gut liefen. Auch bei Meldeschwällen (-schwallen?!), da ich das erzeugen der Meldungen über eine pseudo-Zufallszahl verteilt habe (mit gespeichertem Zeitstempel)
Kann bei Gelegenheit mal nachschauen wie es ungefähr gemacht ist.
Ich habe das bei einem Projekt mit einer 1517F initial gemacht, da war natürlich Power vorhanden.
Es waren geschätzt insgesamt 1500-2000 Instanzen des Bausteins.
Später habe ich das auch auf 1516F und 1512SP laufen gehabt, mit deutlich weniger Instanzen ( ca. 100 bei der 1512SP).
Die Zykluszeiten waren aber alle im Rahmen, sodass es für unsere Anlagen damit gut liefen. Auch bei Meldeschwällen (-schwallen?!), da ich das erzeugen der Meldungen über eine pseudo-Zufallszahl verteilt habe (mit gespeichertem Zeitstempel)
Ja das wäre super! Ich habe nämlich eine 1512 mit ca. 400 Meldungen. Wenn ich die Programm-Alarme permanent aufrufe sind das ca 33ms.
Mit der Routine drum herum sind das 22ms.
Mit der Routine UND dem permanenten Get_AlarmState sind das 44ms :-(
Also erstmal Get_AlarmState wieder entfernt. Nur reduziert sich die Zykluszeit nicht mehr von 44 auf 22 ms
die ist nun mit diesem Programm bei 31ms.Wenn ich eine Sicherung nehme wo das identische Programm drin ist, bin ich wieder bei 22ms. Keine Ahnung was da abgeht...
Also wäre super wenn du mal schaust wie das bei dir war
- Beiträge
- 5.747
- Reaktionspunkte
- 1.690
-> Hier kostenlos registrieren
Meldet er wirklich alle 400 Meldungen, auch wenn diese alle miteinander kommen? Z.B. Meldeschwall?
Die 33ms sind rein "Aufruf" Program_Alarm
- Beiträge
- 9.191
- Reaktionspunkte
- 2.950
Hat denn schon mal jemand bei Siemens eine Support-Anfrage gestellt, warum der Bausteinaufruf so viel Rechenleistung kostet?
Die Frage ist ja, was macht der Baustein da. Der Meldezustand muss ihm intern schon vorliegen, denn die Meldung ans HMI geschieht ja auch nur bei Änderung. Darum ergibt es überhaupt keinen Sinn, um diese intern technisch notwendige Flankenauswertung noch eine eigene Flankenauswertung drumherum bauen zu müssen. Und warum dauert eine Abfrage des Meldezustands so lange? Eine Meldung besitzt eine ID, da schaue ich in einer Liste nach dem Zustand und fertig. Wenn man so ein komplettes Meldesystem im Anwenderprogramm selber inklusive Netzwerkprotokoll zu Fuß ausprogrammiert, ist das vermutlich immer noch leistungsfähiger als das was Siemens da im Betriebssystem verankert hat, und das prinzipbedingt wesentlich schneller sein sollte.
Die Frage ist ja, was macht der Baustein da. Der Meldezustand muss ihm intern schon vorliegen, denn die Meldung ans HMI geschieht ja auch nur bei Änderung. Darum ergibt es überhaupt keinen Sinn, um diese intern technisch notwendige Flankenauswertung noch eine eigene Flankenauswertung drumherum bauen zu müssen. Und warum dauert eine Abfrage des Meldezustands so lange? Eine Meldung besitzt eine ID, da schaue ich in einer Liste nach dem Zustand und fertig. Wenn man so ein komplettes Meldesystem im Anwenderprogramm selber inklusive Netzwerkprotokoll zu Fuß ausprogrammiert, ist das vermutlich immer noch leistungsfähiger als das was Siemens da im Betriebssystem verankert hat, und das prinzipbedingt wesentlich schneller sein sollte.
-> Hier kostenlos registrieren
Jap, das wird so sein.
Ich hatte gestern ein Ticket wegen meinem Problem mit der Zykluszeit eröffnet und nebenbei gefragt ob bzw wie man diesen Baustein am performantesten programmieren kann.
Antwort: "Performanter, als Sie es bereits tuen, wäre der Umstieg auf ProDiag."
Noch Fragen?
