regelmäßige Stockfehler trotz hoher Priorität

Hallo,

ich benötige mal kurz euren Rat. Ich habe im Programm lediglich 2 eigene / zusätzliche OBs im Einsatz. Einer enthält Code, der andere ist nur da, weil er als Referenz für LGF-Bibliotheselemente benötigt wird. Trotzdem habe ich in Traces ca. alle 300 [ms] Aussetzer.

Im Detail:

1. nutze ich einen OB20 (time delay interrupt) als  in dem ich mir einen äquidistanten Takt erzeuge

2. nutze ich einen OB30 (cyclic interrupt), der keinen Code enthält, aber bei Signalgeneratoren aus der LGF-Lib angegeben werden muss

Warum nutze ich den OB20 ?
Ich habe festgestellt, dass die Zeitabstände mit dem gleichen Code äquidistanter sind als durch einen Weckalarm-OB.
Bsp.
Weckalarm: T1 = 9.9 ms; T2 = 13.4 ms; T3 = 7.2 ms usw.
timedelayISR: T1 = 9.9 ms; T2 = 10.3 ms; T3 = 9.2 ms usw.

Die Streuung ist geringer.

Das Problem: Ich habe schon maximal mit allen möglichen Prioritäten herumgespielt. a) ist kein anderer BAustein auf höhere oder gleiche Priorität eingestellt und b) habe ich auch schon statt 15, 16, 17 höhere Zahlen zu verwenden. Also ich möchte sagen, an den Prioritäten kann es nicht liegen.

Coder, der im OB ausgeführt wird und werden soll:

REGION clock signal
 // rectangle clock signal(depends of delay time in globVars.DB)
 "Vars".OB20.clock := NOT "Vars".OB20.clock;
END_REGION

REGION kinematic data and delta t
 // create absolut time vector of "measurements"
 "Vars".DYN.dt := RUNTIME("Vars".DYN.tMem);
 "Vars".DYN.tAbs += "Vars".DYN.dt;

 // directly got wanted kinematic values
 "Vars".DYN.vAx1 := "PositioningAxis_1".ActualVelocity;
END_REGION

REGION next time delay interrupt cycle
 // initiate next time delay interrupt
 "Vars".OB20.srtRV_OB20 := SRT_DINT(OB_NR := 20, DTIME := "Vars".OB20.delay, SIGN := 16#0001);
END_REGION

 Erklärung:
- im ersten Bereich invertiere ich mit jedem Aufruf eine Variable (erzeugt clock signal)
- im zweiten Bereich messe ich mit Runtime Block die Dauer zwischen letzten Aufruf und aktuellem Aufruf (liefert delta t) und hole mir den momentanen Aktualparameter (LREAL-Wert) der Drehzahl in/aus einem Antrieb
- im dritten Bereich starte ich aus dem OB den nächsten timeDelayInterrupt
-> mit diesem OB realisiere ich also die Abtastung des Geschwindigkeitssignals

Im Projektbaum sieht das dann so aus:

-> also im Grunde nichts kritisches erkennbar (afaik). Die Servo-Obs kommen ja automatisch, wenn man mit Achsen arbeitet und sonst eben nur meine erwähnten beiden OBs.

In egal was für Traces, sieht das dann so aus:

Ca. alle 300 [ms] tritt die Störung auf, in der das gesamte Programm mehrere Zyklen lang nicht abgearbeitet wird. Ich hab auch schon überlegt, ob es an überschneidung liegen kann, also bspw.:

2 OBs, gleiche Prio, wenn das geht/ginge, einer alle 10 [ms], der andere alle 4 [ms].
Dann wäre das kleinste gemeinsame Vielfache die 20, also könnte es alle 20 [ms] eine Kollision geben. Aber sowas kann ich ja aus dem bisherigen Gesagtem ausschließen.

Jetzt halt die Frage: läuft irgendwas standardmäßig in einer SPS ab, was so mit 3 Hz Taktes (ca. 300 [ms])? Selbst Phasenverschiedbung zwischen den OBs bringt hier nix.

VG und DAnke im Voraus

:

Huhu Mister T,

vielen Dank für die Antwort.

Nein darüber habe ich tatsächlich noch nie nachgedacht, weil mir bis eben gar nicht bekannt war, dass das möglicherweise eine geeignete Stellschraube sein könnte.

Ich hätte tatsächlich auch gedacht, dass mein Problem mal viel mehr Leuten ein Dorn im Auge war und dass die Resonanz hier höher ist.

Jetzt am WE kann ich die PLC leider nur simulieren und ich habe es gerade noch einmal "double gecheckt", im Simulationsbetrieb habe ich solche Aussetzer erwartungsgemäß nicht. Meine OB20-Aufrufe werden da natürlich ganz sauber bearbeitet und die ISR-Zeit schön äquidistant simuliert:

Abb. 1: Darstellung der fast äquidistanten Aufrufzeit-Abstände meines OB20 im Simulationsbetrieb. Die simulierte PLC lässt hat also keinen Grund, meinen beobachteten Fehler mit zu berechnen / umzusetzen. Alle Zeiten liegen nahezu genau bei 10 [ms] wie es sein soll.

Warum das ganze ?

Hätte ja sein können, dass irgendwelche Fehler auf (Standard-)Einstellungen beruhen und die dann ebenso simuliert werden, sodass ich den Fehler wieder erkenne. Aber wenn ich im Simulatonsbetrieb ein Sinussignal im OB20 berechnen lasse, sind sowohl die Zeitstempel zwischen den OB-Calls und die Werte des Sinus alle tippi toppi.

Deswegen werde ich am Montag, sobald ich wieder Zugang zur Anlage habe, auf jeden Fall deinen Tipp mit der Kommunikationslast versuchen. Gibt es da gängige Experimentierwerte? Wie sensibel ist diese Schnittstelle? Womit muss ich rechnen, wenn ich es zu weit treibe und die (standard) 50 % z. B. auf 20 % reduzieren. Ich habe da noch gar keine Erfahrung und Idee, wie kritisch diese Einstellungen sind.

Der Tooltip / die Hilfe sagt:

Dieser Text hilft mir da nicht wirklich weiter, denn
a) ist die Angabe ja sicherlich bis zu 50 %, also nicht mehr als 50 %
b) habe ich keine anderen CPUs und somit keine diesbezügliche Datenübertragung
c) stoße ich während meiner Anlagenfahrt ja kein "Laden von Bausteinen über PC" an

Blättere ich den Hyperlink zur "Zyklusbalastung durch Kommunikationsprozesse,", sehe ich etwas zusätzliche erläuterung:
(Hinweis: im Folgenden denke ich laut)

• Abs. 1: -

  ... bestimmte MC-Funktionen
  

  Aha, das ist interessant, ich benutze ja MC-Funktionen und brauche die auch (Ich  -> "***"). Ich hoffe natürlich NICHT, dass die die Ursache für die Aussetzer sind. Es wäre für mich äußerst unmöglich das zu testen. Ich bin nicht in der Lage, durch reine Parametersteuerung und Bits-und-Byte-Schubsen meiner Servos so zu steuern, wie mit meinen MC-Bausteinen.
  
• Abs. 3/ -

  Neben den Kommunikationsprozessen verlängern auch Testfunktionen die Zykluszeit. Dabei kann über den Parameter "Zyklusbelastung durch Kommunikation" Einfluss auf die Dauer genommen werden.

  Was sind diesbezüglich Testfunktionen, die da gemeint sind. ist Tracen eine Testfunktion? Weil nur so sind mir die Stockfehler ja aufgefallen. Zykluszeit-genaues Beobachten von Signalen.
  

• Abs. 4 -

  Inbetriebnahme von Technologieobjekten, Restart von Technologieobjekten und Interpolation von Kurvenscheiben

  Threoretischerweise dürften diese Befehle ja nicht während eines stino MC-Befehls Achse Verfahren und so auftreten. Explizit, rufe ich diese jedenfalls nicht auf.

• Hinweis aus dem Abs. 6 -
  

  Hinweis

  Welche Auswirkungen kann die Vorgabe einer minimalen Zykluszeit haben?

  Wenn Sie eine minimale Zykluszeit vorgegeben haben und das Anwenderprogramm diese nicht vollständig benötigt, kann die restliche zur Verfügung stehende Zeit erneut für Kommunikationsprozesse benutzt werden. Dies kann dazu führen, dass Kommunikationsprozesse einen größeren Teil der CPU-Verarbeitungsleistung beanspruchen, als Sie durch den CPU-Parameter "Zyklusbelastung durch Kommunikation" vorgegeben haben

  Ja ich habe eine Mindestzykluszeit vorgegeben. Ich musste den Zyklus von (standard) 1 [ms] auf 2 [ms] stellen, da ich sonst immer für mich nicht lösbare MC-Fehler bekommen habe, die ich auch mit Doku und Recherche nicht lösen konnte. Ein Siemens-Mitarbeiter aus Leipzig hatte mir dann gesagt, dass es durchaus legitim ist, bei Anlagen mit MC-Nutzung die Zykluszeit auf 2 [ms] zu stellen (und ebenso die maximal zulässige Zykluszeit, die bei mir derzeit auf 500 [ms] steht)
  

• Abs. 7/8 - Prioritäten

  Für die Prioritätsklassen kleiner oder gleich 15 wird die Verarbeitungsleistung der Kommunikation ständig von der CPU zugewiesen.

  Prioritätsklassen größer als 15 werden nicht durch Kommunikation unterbrochen

  Da müsste ich auch auf der sicheren Seite sein. Wie gesagt hat mein timeDelayInterrupt OB20 von mir pauschal immer eine sehr hohe Priorität bekommen (aktuell 22).
  
  HALT! zumindest bezüglich meiner Testsignale sehe ich gerade etwas:
  
  Es ist so, dass ich den Weckalarm OB30 ja immer benutzen muss, um z. B. Signalgenerator-Bausteine zu triggern (wie im Post#1 erwähnt). Mein OB30 hatte bis eben aber nur die Priorität 8 und das ist kleiner als 15, und könnte somit von Kommunikation unterbrochen/verzögert werden, was möglicherweise erklären könnte, warum es manchmal keinen neuen Sinuswert gibt und das momentane Signale-Level für mehr als einen Zyklus gehalten wird. Das probiere ich am Montag auch gleich aus und gebe Rückmeldung!
  

•  usw. usf. 

Wenn ich die dann folgenden Beispiele richtig deute, dann stelle ich mit dem Prozentsatz bei "Zyklusbelastung durch Komminikationslast" im Grunde ein, wie sehr der reguläre Zyklus durch Alarme & Kommunikations verlängert werden darf: Laut Beispiel darf der OB1 Zyklus sich bei einer Einstellung der Kommunikationslast auf 50 % um den Fakor 2 verlängern.

Der zweite Hinweis aus dem Beispiel 2 im Hilfetext:

... Die Kommunikationslast muss beim Einstellen der minimalen Zykluszeit berücksichtigt werden, da es sonst zu Zeitfehlern kommen kann. ...

.. ist auch interessant. Wenn ich meinen reinen Zyklus von 1 auf 2 [ms] gestellt habe, habe ich ja keine Veränderung der Kommunikationslast vorgenommen. Möglicherweise hätte ich das tun sollen.

Empfehlungen

• Vergrößern Sie den Wert nur dann, wenn die CPU hauptsächlich zu Kommunikationszwecken eingesetzt wird und das Anwenderprogramm zeitunkritisch ist.

• In allen anderen Fällen sollten Sie den Wert nur verringern.

• Wenn Alarm-OBs nicht durch Kommunikation unterbrochen werden sollen, dann setzen Sie deren Priorität hoch auf einen Wert größer 15.

Punkt 1 - Ok -> d. h. theoretisch muss ich nicht erhöhen
Punkt 2 - Ok -> d. h. das probiere ich am Montag, falls die Umstellung der Priorität des OB30 von 8 auf > 15 nicht ausreicht, auf jeden Fall mal aus
Punkt 3 - Ok -> hab ich jetzt gemacht

Neue Frage von Zottel86 wurde in ein separates Thema mit dem Titel Inwiefern ist eine 1516 CPU dazu geeignet zusätzliche regelungstechnische Aufgaben zu übernehmen? gesplittet.

Gruß
Jen_Moderator

huhu,

vielen Dank für die Reaktion. Also meine Anlage besteht aus

1516 CPU

CU320

2xS120 Umrichter

2x1FT7-..-Servos

Die Antriebe sind via Profinet, bzw drive cliq, angebunden

VG