TIA Grund für Auslösung von NotHalt aus einer VPS sicher erfassen

[uweschwarz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Soweit ich das verstanden habe, werden mit TIA V19 zusätzliche Feature der CPU freigeschaltet.

Nach meiner Erfahrung hilft da, den Anteil von Kommunikation an der Zykluszeit zu verringern, z.B. auf 20%

Guter Hinweis. Im Moment sind 40% eingestellt. Werde ich bei nächster Gelegenheit ändern. Welche Auswirkungen hat das im schlechtesten Fall?

 

[PN/DP]

Wenn man seeehr viel HMI-Kommunikation hat, dann können evtl. nicht mehr alle Variablen der Visu/HMI im gewünschten bzw. eingestellten Zeitintervall aktualisiert werden (das ist aber meist kein Problem). Und beim Online-gehen von TIA rödelt das etwas länger, bis alle farbigen Bälle an den Objekten im Objektbaum angemalt sind. Für den zu steuernden Prozess "ernste" Folgen sind mir keine bekannt (noch nicht erlebt).

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Soweit ich das verstanden habe, werden mit TIA V19 zusätzliche Feature der CPU freigeschaltet.

aber auch, wenn man nicht mit V19 projektiert, sondern z.B. V17, dann profitiert man von der schnelleren Firmware (mit weniger künstlicher Handbremse ) und dem mehr freigeschalteten Speicher.

 

[Larry Laffer]

Allerdings habe ich etliche PID-Regler Aufrufe (ca. 30), die ich momentan nicht brauche, weil die Funktionalität noch nicht benötigt wird. Ich könnte die deaktivieren, können dabei gigantische Einsparuren, die es ja bräuchte, zusammenkommen?

Das kommt auf deine Umsetzung an ...

Die Analogwertverarbeitung mache ich in einem Baustein mit gut 200 Instanzen. Kann es daran liegen?

Das musst du mir mal erklären - was machst du denn da wie ?

 

[uweschwarz]

dann profitiert man von der schnelleren Firmware

Ok, fair enough Wenn ich's richtig verstanden habe, geht's doch aber um folgendes: Entweder ist irgendein krasser Programmierfehler oder eine zu kleine CPU für die langen Zykluszeiten verantwortlich.

Besonders auf while und repeat schleifen würde ich mein Augenmerk richten.
Oder Aufrufe von GetSymbolName etc., wo zur Laufzeit irgendetwas aufgelöst wird...

Solche und auch andere Schleifen werden gar nicht oder nur sehr selten verwendet. GetSymbolName: könnte sein, dass in der LBP irgendwo versteckt solche Abfragen sind. Ich selbst oder mein Kollegen der mit programmiert hatte brauchen das nicht.

Das musst du mir mal erklären - was machst du denn da wie ?

Ich rufe für die Analogwerte jeweils eine Instanz des LBP_AnaRead auf. Insgesamt ca. 200 mal.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Allerdings habe ich etliche PID-Regler Aufrufe (ca. 30), die ich momentan nicht brauche, weil die Funktionalität noch nicht benötigt wird. Ich könnte die deaktivieren,

Das bringt im Grunde nichts und wäre nur kurzfristige vergängliche Kosmetik, weil irgendwann brauchst du die ja bestimmt. Und wenn du die dann aktivierst, macht die Zykluszeit plötzlich einen Sprung und das vorher funktionierende Programm funktioniert dann nicht mehr so schön. Vielleicht stoppen Achsen an Lichtschranken etwas später, Positionierungen fahren am Zielpunkt hin und her, Bediener müssen Taster länger drücken, damit die PLC das mitkriegt, ...

 

[Larry Laffer]

Ich rufe für die Analogwerte jeweils eine Instanz des LBP_AnaRead auf. Insgesamt ca. 200 mal.

Anhang anzeigen 89478

Ich habe keine Ahnung was der intern treibt - nimm den doch mal spsseshalber raus und schau wo du dann landest. Ich habe sowas nie mit einem derartigen Baustein gemacht. Du brauchst doch im Grunde nur den Analog-IN einlesen und dann skalieren/normieren ...

 

[uweschwarz]

Du brauchst doch im Grunde nur den Analog-IN einlesen und dann skalieren/normieren ...

Der LBP macht noch mehr: Grenzwertauswertung, Auswahl Peripheriewert (unipolar, bipolar, faktor 0,1, etc), Breitstellung der Schnittstelle für HMI, Simulation des PV, Überschreiben der PLC-Einstellung durch HMI, und und und ... Siemens halt

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ach, DESHALB muss die CPU-Performance steigen.
Nicht, weil die Anwendungsprogrammierer oder Kunden mehr Leistung benötigen, sondern, weil SIEMENS eierlegende Wollmilchsau-Bausteine entwickelt, die sonst nicht nutzbar wären.

Vielleicht ist es an der Zeit den LBP über Bord zu werfen und nur das zu programmieren, was wirklich benötigt wird.

 

[Larry Laffer]

... ich hätte jetzt aber doch schon gerne gewußt wie die Zykluszeit-Belastung durch die 200 Baustein-Aufrufe aussieht ...

Du solltest bei deiner Zykluszeit-Betrachtung aber von dem Nominalwert ausgehen. Wer weiß wo dein Wert 200 ms ursprünglich mal hergekommen ist ...

 

[uweschwarz]

Vielleicht ist es an der Zeit den LBP über Bord zu werfen und nur das zu programmieren, was wirklich benötigt wird.

Ich gebe zu das die Zykluszeitbelastung ein Nachteil ist, ein weiterer Nachteil ist, dass die Bausteine nicht fehlerfrei waren. Das Design ist aufwändig und erfordert hohe Einarbeitungszeit, wenn man etwas tiefer einsteigen will.
Für mich überwiegen die Vorteile trotzdem. Ich habe schlicht keine Zeit eine eigene Bausteinbibliothek mit Visualisierung zu entwickeln, zu testen und zu dokumentieren(!). Ich bin hier der einzige SPS Programmierer, entwickle, gemeinsam mit den Wissenschaftlern, das Programm weiter, mache noch Teamleitung und Vertretung der Projektleitung. Wenn mir jemand einen Studenten schickt, wäre ich sehr dankbar. Eventuell könnte das sogar ein Thema für eine Masterarbeit sein

 

[uweschwarz]

Zuviel Werbung?
-> Hier kostenlos registrieren

... ich hätte jetzt aber doch schon gerne gewußt wie die Zykluszeit-Belastung durch die 200 Baustein-Aufrufe aussieht ...

Kann ich dir Montag sagen

 

[Larry Laffer]

Ich gebe zu das die Zykluszeitbelastung ein Nachteil ist, ein weiterer Nachteil ist, dass die Bausteine nicht fehlerfrei waren. Das Design ist aufwändig und erfordert hohe Einarbeitungszeit, wenn man etwas tiefer einsteigen will.

Das war ja mein Ansatz ...

Für mich überwiegen die Vorteile trotzdem. Ich habe schlicht keine Zeit eine eigene Bausteinbibliothek mit Visualisierung zu entwickeln, zu testen und zu dokumentieren(!).

So etwas macht man ja auch so nach und nach und nicht alles auf ein Mal. Das was du hier schreibst widerspricht sich dann aber mit dem Text hier drüber ...

Ich bin hier der einzige SPS Programmierer, entwickle, gemeinsam mit den Wissenschaftlern, das Programm weiter, mache noch Teamleitung und Vertretung der Projektleitung. Wenn mir jemand einen Studenten schickt, wäre ich sehr dankbar. Eventuell könnte das sogar ein Thema für eine Masterarbeit sein

Wo ein Wille da auch ein Gebüsch ...

 

[uweschwarz]

So etwas macht man ja auch so nach und nach und nicht alles auf ein Mal

Das könnte ich in der Tat mal versuchen.

 

[uweschwarz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe jetzt so gemacht:

REGION Init
  
    #Inst_R_TRIG_startUp(CLK := #SPS_Neustart);
    
    IF #Inst_R_TRIG_startUp.Q OR #Reset THEN
        #stati := 0;
        #statj := 0;
        FOR #stati := 0 TO 100 DO
            #Messwertpuffer[#stati] := 0;
        END_FOR;
        FOR #stati := 0 TO 100 DO
            #Zeitstempel[#stati] := DTL#1970-01-01-00:00:00;
        END_FOR;
        #statJetzt := DTL#1970-01-01-00:00:00;
        #statFreigabe_Einlesen:=False;
        #NotHaltUrsache := false;
        #Auslösewert := 0.0;
      
        
        
    END_IF;
    
END_REGION



REGION Werte speichern
    
    #statFreigabe_Einlesen := NOT #Reset AND NOT #Trigger AND #Enable_speichern;
    IF #statFreigabe_Einlesen THEN
        FOR #statj := 99 TO 0 BY -1 DO
            #Messwertpuffer[#statj + 1] := #Messwertpuffer[#statj];
            #Zeitstempel[#statj + 1] := #Zeitstempel[#statj];
        END_FOR;
        #Messwertpuffer[0] := #Wert;
        #RET_VAL_LOC_Time := RD_LOC_T(#statJetzt);
        #Zeitstempel[0] := #statJetzt;
    END_IF;
    
END_REGION

REGION Auslösewert speichern
    
    #inst_R_TRIG_Auslösewert(CLK := #Trigger);

    IF #inst_R_TRIG_Auslösewert.Q THEN
        // Wert der zum Zeitpunkt des Eintretens der Triggerbedingung aktuell war speichern
        #Auslösewert := #Wert;
    END_IF;
    
END_REGION
REGION _Auswertung
    IF #Enable_auswerten THEN
        IF #Auslösewert >= #Alarmwert THEN
            //ich war es
            #NotHaltUrsache := true;
        END_IF;
    END_IF;
    
END_REGION

 

[Larry Laffer]

wofür benötigst du den Zeitstempel ? Der bläht die Angelegenheit nur unnötig auf und frisst auch im FIFO viel Performance beim Umspeichern.
Wenn überhaupt würde ich den für den ersten Wert ablegen - alle weiteren Werte werden doch in einem fixen Intervall hinterlegt ...

 

[uweschwarz]

wofür benötigst du den Zeitstempel ? Der bläht die Angelegenheit nur unnötig auf

Hast recht. Ist etwas zuviel, der erste Wert reicht.

 

[Mrtain]

Zuviel Werbung?
-> Hier kostenlos registrieren

        FOR #stati := 0 TO 100 DO
            #Messwertpuffer[#stati] := 0;
        END_FOR;
        FOR #stati := 0 TO 100 DO
            #Zeitstempel[#stati] := DTL#1970-01-01-00:00:00;
        END_FOR;

Lässt sich vereinfachen zu

        FOR #stati := 0 TO 100 DO
            #Messwertpuffer[#stati] := 0;
            #Zeitstempel[#stati] := DTL#1970-01-01-00:00:00;
        END_FOR;

Spart eine schleife

 

[uweschwarz]

Spart eine schleife

Stimmt, aber jetzt hat mich Larry ja überredet den Zeitstempel nur für den ersten Wert zu speichern

 

[uweschwarz]

... ich hätte jetzt aber doch schon gerne gewußt wie die Zykluszeit-Belastung durch die 200 Baustein-Aufrufe aussieht ...

Zykluszeit bei Reduktion der Kommunikationslast von 40% auf 20% bleibt etwa gleich. Nach auskommentieren der 200 Bausteinaufrufe sinkt die Zykluszeit um ca. 15ms auf etwa 65ms