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

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe es mal so versucht:
Code:
(...)
            #Messwertpuffer[#statj + 1] := #Messwertpuffer[#statj];
Tipp: bei großen Arrays sollte man das Umspeichern des kompletten Arrays vermeiden (Zykluszeitfresser). Besser als Ringpuffer programmieren, da muss man sich beim Hinzufügen nur zusätzlich merken, wo gerade das Ende des Puffers ist (Ende-Zeiger). Neue Elemente brauchen immer nur das aktuell letzte/älteste Element überschreiben + Ende-Zeiger eine Position weitersetzen.
 
Eines vielleicht noch :
Ich hatte sowas immer mit einer CPU gemacht, die nicht so schnell wie deine 1516 war und das Programm hatte auch eine relativ hohe Zykluszeit (für mich - es waren > 20 ms). Die Messung musste aber stellenweise im 5 ms-Takt (verlässlich) stattfinden.
Ob du das also auch so machen musst ist vielleicht auch eine Frage deiner Zykluszeit und deines Wunsch-Intervalls der Messung ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@PN/DP : er hat hier ja ein Array mit 100 Elementen - da sollte das noch keine Problem darstellen. Mein Vorschlag mit dem FIFO zielte aber auch dahin, dass ich mir vorstellen kann, dass der OP das ggf. auch irgendwann visualisieren möchte ... und dann ist ein Ringpuffer ja nicht ganz so optimal ... (wegen der Darstellung)
 
aus dem Grund hatte ich dir (ein paar Beiträge zurück) geschrieben
Ja, genau. Diesen Beitrag hatte/habe ich vielleicht nicht richtig verstanden.
Es gibt verschiedene IN-Parameter.
Zum Beispiel: IN1: speichere_Messwerte_in_FIFO und IN2: werte_die Messergebnisse_aus
Beim Aufruf im schnellen OB ist IN1 True und beim Aufruf im zyklischen Programm ist IN2 True
Soweit korrekt?
Ich frage mich halt welchen Wert ich im schnellen OB speichere. Den Rohwert, der von der Karte kommt oder den skalierten Wert aus dem zyklischen Programm. Eigentlich doch den Rohwert von der Karte, oder?
Ob du das also auch so machen musst ist vielleicht auch eine Frage deiner Zykluszeit und deines Wunsch-Intervalls der Messung ...
Als kürzeste Zykluszeit wird aktuell 80 ms und längste 199ms angezeigt.
Ehrlich gesagt habe ich keine Ahnung wie groß mein Wunsch Intervall ist. Meine Grenzen sind ca. 10% unter der Grenze der VPS. Wenn ein Druckstoß kommt, der die VPS auslöst, würde ich gern so schnell wie möglich sein.
 
Also ...
Den jeweils nicht benutzten IN musst du dann aber gezielt auf False setzen ...
Als Intervall würde ich 10 ms anpeilen für den OB.
Über deine Zykluszeit bin ich aber, ehrlich gesagt, etwas erschrocken. Was macht denn dein Programm, dass du so gigantische Werte bekommst ?
Auf jeden Fall ist es da kein Wunder, dass du den Analogwert, den du erfassen möchtest, nicht mitbekommst ...
Ich würde NICHT den Rohwert speichern sondern den schon skalierten. Das heißt dann natürlich, dass du das Skalieren auch in dem Zeit-OB machen musst - sonst hast du ja nichts gewonnen.
 
bei einer S7-1516 sind so gigantisch hohe Werte unnormal. Irgendwas ist da vermutlich falsch realisiert.
Sch.. was nu? Ich wusste nicht, dass das gigantisch hoch ist.
Ich dachte immer: Wir haben ca. 150 Sensoren und 35 Motore, ca 50 Absperrventile, 30 Stellventile, Profibus, Profinet, Modbus und Kleinkram. Noch dazu die aufwändige LBP Bibliothek. Das ist schon einiges.
Was könnte falsch realisiert sein? Welche Zykluszeit wäre nicht gigantisch hoch? Wie kann ich das feststellen?
 
Verwendet ihr viele schleifen?
Danach würde ich erstmal suchen. Besonders auf while und repeat schleifen würde ich mein Augenmerk richten.
Oder Aufrufe von GetSymbolName etc., wo zur Laufzeit irgendetwas aufgelöst wird...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Welche Zykluszeit wäre nicht gigantisch hoch? Wie kann ich das feststellen?
Eine Zykluszeit von 20 bis 50 ms würde ich bei der CPU und der von dir genannten Hardware als realistisch ansehen.
Ich weiß jetzt ja nicht, was du für Bibliothek-Bausteine eingesetzt hast und wie - ganz allgemein habe ich aber die Erfahrung gemacht, dass wenn die Baustein ZUUUU allgemein gehalten sind (wie z.B. das von dir ursprünglich angepeilte FIFO) dann verbrauchen die auch Performance.
Ansonsten, wie schon von @Mrtain genannt, solltest du nach Schleifen suchen und schauen ob das wirklich immer so notwendig ist wie aktuell umgesetzt.
Immer dran denken : die von dir eingesetzte CPU ist jetzt schon nicht schlecht ... (die ist nun nicht gerade eine Schnecke)
 
Und der Program_Alarm lässt die Zykluszeit nach oben schießen.

"Falsche Realisierung" muss nicht unbedingt eine "falsche" oder aufwändige Programmierung sein. Vielleicht ist die CPU einfach zu klein dimensioniert?
 
Bei den Steuerungen gab es ein Upgrade.

Neben dem Speicher und anderen Themen betrifft das auch die Geschwindigkeit.

Tabelle Bit-Operation
altneu
151160ns6ns
151340ns6ns
151530ns6ns
151630ns6ns
15172ns0,6ns
15181ns0,3ns

Also, wenn Du eine "neue", statt einer "alten" 1516 hast, bist Du 5x schneller.

Bei
80 ms und längste 199ms
sind das dann 16 - 40ms.

Also erstmal die Frage, was hast Du GENAU für eine CPU (Bestellnummer)?


VG
MFreiberger
 
6ES7 516-3AN02-0AB0 Firmware-Version V2.9
Das ist vermutlich die Version, als die die CPU offline projektiert ist?
Welche Firmwareversion wirklich auf der CPU ist, musst du online nachsehen.

Aktuell wäre für die 516-3AN02 V2.9.8
ob da auch Geschwindigkeitsverbesserungen bei sind, habe ich nicht nachgeschaut.

( Achtung: auch bei dieser CPU wird in einem anderen Siemens-Support-Beitrag etwas abweichendes genannt: V2.9.7 )
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Schleifen habe ich eigentlich nur für die Messwertpufferung genutzt.
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?
Ich weiß nicht wo die 199ms herkommen, aber im Moment, Anlage ist gerade unter Last, pendelt die Zykluszeit um die 90ms. Das wäre ja der ungefähr dreifache Wert dessen, was ihr als normal ansehen würdet.
Die Analogwertverarbeitung mache ich in einem Baustein mit gut 200 Instanzen. Kann es daran liegen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich weiß nicht wo die 199ms herkommen
ich vermute mal, vom online-verbinden mit TIA. TIA überflutet gerne die CPU übermäßig mit PG-Kommunikation beim online-verbinden. Nach meiner Erfahrung hilft da, den Anteil von Kommunikation an der Zykluszeit zu verringern, z.B. auf 20%
Zykluszeit 199ms ist eigentlich schon ein Fall, wo die Zykluszeit-Überwachung zuschlagen sollte.
 
Vielleicht ist es Zeit auf eine 1517 zu wechseln?
Er hat ja noch eine Firmware V3.x auf der CPU.

Ab Firmware 4.x.x wird bei seiner CPU mehr Performance "freigeschaltet":
Update V4.0.0 für 6ES751x-xxx03-0AB0
  • 100% mehr Programmspeicher
  • Performancesteigerung je nach CPU und STEP7 Projekt um bis zu Faktor 3
  • Zusätzlicher Performance Boost (+ 25%)für CPUs 1518(F)-3 PN und 1518T(F)-3 PN
  • Höhere Kommunikations-Performance
    • Performancesteigerung bei OPC UA und Web-API (Read/Write) um bis zu 200%
    • Performancesteigerung bei OUC um bis zu 80%


EDIT:
Oder betraf das nur die T(F)-CPU´s, ich bin mir gerade nicht sicher.
 
Zurück
Oben