TIA Hängende ProgramAlarme

Jochen Kühner

Level-3
Beiträge
4.488
Reaktionspunkte
728
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wir setzen nun intensiv ProgramAlarm ein, und haben ab und an das Problem das sie hängen bleiben. Können aber nicht nicht wirklich genau darauf schließen was die Ursache ist! Habt Ihr das als auch? Wenn ja, was macht Ihr dagegen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wir setzen nun intensiv ProgramAlarm ein, und haben ab und an das Problem das sie hängen bleiben. Können aber nicht nicht wirklich genau darauf schließen was die Ursache ist! Habt Ihr das als auch? Wenn ja, was macht Ihr dagegen?

Ich habe mal eine Dosiersteuerung inkl. Materialverwaltung und Rezepturen programmiert. Dort habe ich intensiv ProgramAlarm eingesetzt.
Wenn man ein Material löschen wollte habe ich in einer Schleife über alle Rezepte überwacht ob dieses Material nicht in einem Rezept verwendet wird.
Kam es nun vor das zwei ProgramAlarm Aufrufe in sehr kurzer Zeit stattfanden wurde der zweite ProgramAlarm "verschluckt". Ich habe damals ein Wait (Achtung Angabe in µs) eingebaut und der ProgramAlarm funktionierte wieder.

Sprich zwischen zwei ProgramAlarm Aufrufen muss eine Mindestzeit liegen.
 
Ich hatte das nur in einem Fall bisher, wenn ich einen Programm_Alarm mit einem FB auslöse und dann den Fehler-FB mit diesem auslösenden Programm_Alarm deaktiviere (Aufruf löschen), weil ich merke, den brauchen ich nicht, dann "hing" so ein Alarm auch, bis man die SPS ausgeschalten und neu gestartet hat. Vielleicht ruft ihr die Programm-Alarme nach dem "Auslösen" manchmal nicht mehr auf?

@miasma
Reicht ein Zyklus? denn wenn man im ganzen SPS-Programm verstreut Programm_Alarm nutzt, kann das schon passieren. Ich hatte das bisher noch nie, bin aber rein statistisch sicher, dass es zumindest zufällig schon mal kurz hintereinander Alarme gibt. Bisher keine Auffälligkeiten erlebt.
 
Hallo zusammen,

ihr fangt jetzt hoffentlich nicht ernsthaft eine Diskussion an, wie man die Fehler von Programm_Alarmen umschifft!? :confused:

Sollte es zu Fehlfunktionen kommen können, wenn mehrere Programm_Alarme zeitgleich oder mit „zu kurzem“ Abstand auflaufen, dann hat hier der Hersteller schnellstens Abhilfe zu schaffen! :evil:

Wo kommen wir hin, wenn Programme nur noch unter bestimmten Bedingen funktionieren, die nicht einmal genau bekannt sind.

LG Cassandra
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ihr fangt jetzt hoffentlich nicht ernsthaft eine Diskussion an, wie man die Fehler von Programm_Alarmen umschifft!? :confused:

Sollte es zu Fehlfunktionen kommen können, wenn mehrere Programm_Alarme zeitgleich oder mit „zu kurzem“ Abstand auflaufen, dann hat hier der Hersteller schnellstens Abhilfe zu schaffen! :evil:

Wo kommen wir hin, wenn Programme nur noch unter bestimmten Bedingen funktionieren, die nicht einmal genau bekannt sind.
LG Cassandra

Nein, es geht eher im die richtige Verwendung von Programm_Alarm, denke ich mal. (Zumindest aus meiner Sicht)
Bzw., darum, ob ein Fehler beobachtet wurde oder ob es eher eine fehlerhafte Verwendung ist.
Das muß man ja wohl immer zuerst versuchen abzuklären und das ist nicht immer einfach.
 
ProgramAlarm nutze ich nicht, aber das ist ein anderes Thema.

Die geschilderten Effekte kenne ich jedoch auch von Bit-Meldungen aus der Classic-Welt. Ich vermute, dass die Ursache an der selben Stelle zu finden ist. Und zwar liegt es an der Kommunikation zwischen CPU und HMI. Derartige Fehler traten dann auf, wenn die Zykluszeit des OB1 sehr klein war und/oder das Meldereignis nur sehr kurz (ein oder zwei Zyklen) anstand. Abhilfe war, mehr Zeit für die HMI-Kommunikation zu schaffen. Hierfür gab es in den CPU-Einstellungen entsprechende Parameter. Bei sehr kleinen Zykluszeiten konnte man auch gewinnbringend den OB1-Zyklus verlängern. Es betraf übrigens nur Verbindungen über Ethernet, niemals Anlagen mit Softbus.

Falls jetzt einer sagt "..habe ich an meinen Anlagen nie gehabt .." Sehr oft wird, um eben solche Widrigkeiten zu umgehen, einfach das gespeicherte Meldebit als HMI-Meldung verwendet, nicht aber das eigentliche Meldeereignis. Dann kann dieser Effekt natürlich nicht auftreten. Man hat dann aber auch nicht alle Meldezustände.
 
Die Kombination WinCC Prof. V13 mit TIA V13 läuft problemlos. V12 bis V13 ohne SP1 hatte auf der SCADA Seite ein paar Probleme. Seit SP1 läuft das ganze ausgezeichnet. Auch die Systemmeldungen funktionieren.

TIA V14 und WinCC V7.4 hackt etwas. Hier gibt es ein paar Schönheitsfehler mit dem Scada Export/Import. Upd. 6 soll hier Abhilfe schaffen. Ob damit die Systemmeldungen komplett unterstützt werden weiß ich nicht. Hier warte ich noch auf eine Antwort.

Was immer hilft ist ein Vergleich der Meldungen auf der SPS mit denen auf dem SCADA System. Da hat man dann halt was auf der Hand wenn man mit Siemens in Kontakt tritt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@miasma
Reicht ein Zyklus? denn wenn man im ganzen SPS-Programm verstreut Programm_Alarm nutzt, kann das schon passieren. Ich hatte das bisher noch nie, bin aber rein statistisch sicher, dass es zumindest zufällig schon mal kurz hintereinander Alarme gibt. Bisher keine Auffälligkeiten erlebt.

Ich meine das ich seinerzeit 100µs genommen haben als Wert für den Wait.
 
Ich meine das ich seinerzeit 100µs genommen haben als Wert für den Wait.
Vorausgesetzt, das war wirklich die Ursache, dann deutet es darauf hin, dass was im Argen liegt. Dann ist auch damit zu rechen, dass es bei einem Wechsel zwischen unterschiedlich leistungsfähigen CPU’s zu Problemen kommen kann!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vorausgesetzt, das war wirklich die Ursache, dann deutet es darauf hin, dass was im Argen liegt. Dann ist auch damit zu rechen, dass es bei einem Wechsel zwischen unterschiedlich leistungsfähigen CPU’s zu Problemen kommen kann!

Vor allen Dingen ist es nicht Dokumentiert von Siemens, wie man das
Zykluszeitmonster richtig einsetzen darf. Wie viele Ausnahmefälle muss
man noch beachten, die einen irgendwann auf die Füße fallen, wenn Projekte
auf der ganzen Welt verteilt sind?
 
Hallo,

wir setzen nun intensiv ProgramAlarm ein, und haben ab und an das Problem das sie hängen bleiben. Können aber nicht nicht wirklich genau darauf schließen was die Ursache ist! Habt Ihr das als auch? Wenn ja, was macht Ihr dagegen?

Ich kan so ein Verhalten bestätigen,
Im Moment das mann:
Wenn nicht optimierte FB verwendet wird, und mann den Bausteinnummer nachträglich noch mal ändert. Sprich wenn die schon auf der SPS geladen war. Hier muss mann abhilfe schaffen durch löschen, übersetzen, laden und neu Baustein einfügen.
Überspringen von Programmalarme, wenn ein Alarm da ansteht. Sprich, erst den Alarm "auf false"

Zykluszeitproblemen bei Kurze Zyklus kann ich nicht bestätigen.

Bram
 
Wir verwenden bspw. Folgenden Code für den Prg Alarm:

Code:
REGION Plausibility Check
    // Plausibilität Daten
    IF #Place.OperationMode.AutomaticMode AND NOT #PlaceData.MOrder.DataPresent AND #Place.Signals.PlaceOccupied AND NOT #Place.Signals.MoveActive AND NOT #Place.Signals.MoveOnEngineAxis1Active AND NOT #Place.Signals.MoveOnEngineAxis3Active AND NOT #Place.Config.IgnoreGeneralPlausibility AND NOT "General".Simulation THEN
        #StartDataPlausibilityTime := TRUE;
    ELSE
        #StartDataPlausibilityTime := FALSE;
    END_IF;
    
    #IEC_Timer_DataPlausibility(IN := #StartDataPlausibilityTime,
                                PT := #Place.Config.TimeGeneralPlausibility,
                                Q => #TimerDataPlausibilityError);
    
    IF #Place.Signals.Acknowledge THEN
        #DataPlausibilityError := FALSE;
    END_IF;
    
    IF #TimerDataPlausibilityError THEN
        #DataPlausibilityError := TRUE;
        #Place.Signals.Disturbed := TRUE;
    END_IF;
    
    REGION Program Alarm Data Plausibility 
        
        // Sammelstörung setzen
        IF #DataPlausibilityError THEN
            "General".TempAlarmActive := TRUE;
        END_IF;
        
        // Trigger für Alarm bilden
        #signalProgramAlarm := #DataPlausibilityError OR "General".SetAllErrorMessages;
        
        // prüfen ob Alarm ausgelöst oder quittiert werden soll
        IF #signalProgramAlarm AND NOT #LastSignalProgramAlarm[1] AND NOT #TriggerAlarm[1] THEN
            #TriggerAlarm[1] := TRUE;
            #TimestampProgramAlarm[1] := "General".DateAndTimeUTC;
        ELSIF NOT #signalProgramAlarm AND #LastSignalProgramAlarm[1] AND NOT #ResetAlarm[1] THEN
            #ResetAlarm[1] := TRUE;
            #TimestampProgramAlarm[1] := "General".DateAndTimeUTC;
        END_IF;
        
        // Alarm auslösen oder quittieren
        IF #TriggerAlarm[1] AND "General".MessageCounter < "MESSAGES_PER_CYCLE" THEN
            #Program_Alarm_DataPlausibilityError(SIG := TRUE,
                                                 TIMESTAMP := #TimestampProgramAlarm[1],
                                                 SD_1 := #Place.Config.Name);
            #GetAlarmStateAfterTrigger[1] := TRUE;
            "General".MessageCounter := "General".MessageCounter + 1;
        ELSIF #ResetAlarm[1] AND "General".MessageCounter < "MESSAGES_PER_CYCLE" THEN
            #Program_Alarm_DataPlausibilityError(SIG := FALSE,
                                                 TIMESTAMP := #TimestampProgramAlarm[1],
                                                 SD_1 := #Place.Config.Name);
            #GetAlarmStateAfterReset[1] := TRUE;
            "General".MessageCounter := "General".MessageCounter + 1;
        END_IF;
        
        // Status Program Alarm nach dem Auslösen prüfen
        IF #GetAlarmStateAfterTrigger[1] THEN
            Get_AlarmState(Alarm := #Program_Alarm_DataPlausibilityError,
                           AlarmState => #alarmState,
                           Error => #errorGetAlarmState,
                           STATUS => #errorStatus);
            IF #TriggerAlarm[1] AND #alarmState = 16#87 THEN
                #TriggerAlarm[1] := FALSE;
                #GetAlarmStateAfterTrigger[1] := FALSE;
                IF NOT #signalProgramAlarm THEN
                    #ResetAlarm[1] := TRUE;
                END_IF;
            END_IF;
        END_IF;
        
        // Status Program Alarm nach dem Rücksetzen prüfen
        IF #GetAlarmStateAfterReset[1] THEN
            Get_AlarmState(Alarm := #Program_Alarm_DataPlausibilityError,
                           AlarmState => #alarmState,
                           Error => #errorGetAlarmState,
                           STATUS => #errorStatus);
            IF #ResetAlarm[1] AND #alarmState = 16#86 THEN
                #ResetAlarm[1] := FALSE;
                #GetAlarmStateAfterReset[1] := FALSE;
                IF #signalProgramAlarm THEN
                    #TriggerAlarm[1] := TRUE;
                END_IF;
            END_IF;
        END_IF;
        
        // Trigger Signal für Flankenauswertung speichern
        #LastSignalProgramAlarm[1] := #signalProgramAlarm;
    END_REGION
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nun hatten wir z.B. schon das Problem das "Get_AlarmState" nicht den richtigen Status zurückgeliefert hat.

Oder das "Get_AlarmState" den Fehler 8002 ("ID der Meldung ungültig") geliefert hat! Aber welche ID soll den ungültig sein?

Problem ist einfach, wir konnten nicht mehr nachstellen was unsere Inbetriebnehmer alles gemacht hatten... Weg bekommen haben wir es manchmal durch Start/Stop und manchmal durch neues Antriggern.
 
Hallo Jochen,
ich finde deinen Aufruf des ProgramAlarm etwas Rustikal, vielleicht
wird da etwas in der If .. ELSIF.. Anweisung verschluckt.

Ich würde den Program Alarm eher zyklisch aufrufen und maximal nur die
Zuweisungen über sagen wir mal „Schmiermerker“ in IF .. THEN Zuweisungen
verwalten.
 
Problem ist, wir wollen gewisse Störungen "sicher" auslösen, und wir können nicht unbegrenzt viele Alarme pro zyklus auslösen. Daher müssen wir abfragen ob der Alarm ausgelöst wurde!

Verschluckt wurde nichts, wir hatten z.b. das Get_AlarmState gebracht hat der Alarm liegt an, aber ein Aufruf des "#Program_Alarm" mit False hat ihn nicht zurück geserzt!
 
Da stolle ist natürlich auch noch, das wir diese Logik nicht wirklich kapseln können, da man ja direkt am PrgAlarm Baustein die Texte Editiert!

Das ist so nicht ganz richtig. Die Meldungen können unter PLC Überwachungen & Meldungen zentral verwaltet bzw. deren Texte projektiert werden. Achtung es muss der Reiter Meldungen offen sein und darunter der Reiter Programmeldungen.

Es macht auch Sinn unter dem Menu Extras/Einstellungen/PLC-Meldungen/Meldungseditor das Häckchen bei "Verriegelungssymbole anzeigen" zu setzen.
Damit man auch Meldungen bearbeiten kann die gekapselt sind bzw. alternative Meldetexte brauchen.
 
Zuletzt bearbeitet:
Zurück
Oben