Verhalten des Submit Interpreters

wenn du den Sub so voll packst dauert der zyklus einfach länger.
hatte bei aufwendigen sachen schon mal um die 2 sekunden.
mehrfach wird nichts aufgerufen.

du solltest gewissen sachen im sub nur machen wenn sie auch nötig sind z.B. die aufwendige Berechnung nur wenn sich etwas geändert hat

Gruß Loipe

Hallo,

langsame Zykluszeiten im SPS.SUB hatte ich auch schon - Sekunden hatte ich aber definitiv noch nie. Da ist was anderes faul.

Ich vermute eher, das dein SRC in einer kurzen Schleife rumhuepft und sich die Bedingung darin andert.
Dein Sps.sub hat eine langere Zykluszeit und die bedingung ist nur alle schaltjahr mal true.
Sollte in deinem SRC nicht was wie

Bedingung = TRUE
while Bedingung
endwhile

programmiert sein, bin ich auch ueberfragt und stell mir die Frage, was ihr da alles in den sps.sub reinpackt.

Gruss Stefan

Hallo,

das mit dem Zugriff auf E/as hat keinen Einfluss.
Die vermutung hatte ich auch mal.
Hab dann alles in ein Prozessabilod kopiert und im Ablauf den Mist wieder aus Arrays rausklamuesert
resultat -> noch viel langsamer.

Hintergrund ist vermutlich, das Submit Interpreter und Roboter Interpreter Zeilenorientiert arbeiten.
D.h. eine Anweisung je IPO-Takt. Zudem hat der Submitinterpreter eine niedrigere Prioritaet.

Gruss Stefan

Hallo,

habe mir jetzt mal einen SUB-Drehzahlmesser gebaut.
Die SUB meines jetzigen Roboter läuft demnach ca. 70 U/Sekunde, im Standby. Und die ist schon ganz schön groß!

Merkwürdiger Weise wird die SUB nicht langsamer, wenn ich in der Robotertask eine LOOP ENDLOOP Schleife laufen lasse.
Auch wenn ich in dieser Loop Ausgänge setze hat es keine Auswirkung aus die SUB.
Aber die BOF reagiert viel langsamer.

Ciao, Andreas

Hallo,

ich würde auch gerne die Durchlaufzeit meines SPS.sub ermitteln, welche Methode bzw. Programm benutzt ihr???

$CYCFLAG

In die SUB:
U/s:

$TIMER_STOP[3] = FALSE
  IF $TIMER[3] >= 1000 THEN
    DREHZAHL = q
    $TIMER[3] = 0
    q = 0
  ELSE
    q = q + 1
  ENDIF

DREHZAHL und q dürfen natürlich keine Laufzeitvariablen sein

Hallo,

niedrigste Prioritaet hat Windows. Es wird ein Interrupt ausgeleoesst, welcher das Windows wieder zum Zuge kommen laesst.
Frueher war das ein NMI, der von einem Taktgeber auf der MFC ausgeloesst wurde, heute ist es vermutlich Software.

Waere der Roboter zu 100% ausgelastet, bekaeme Windows gar keine Rechenzeit mehr.
D.H. da wird zwischen Windows und VxWork geswitcht.

Roboterinterpreter und Submit Interpreter werden von einem Taskscheduler, der unter VxWorx laeuft, verwaltet.

Die Performance von SPS.Sub und Bof sind daher nicht vergleichbar.

Gruss Stefan

Ich weiss nur, dass jede Zeile im SPS.sub (auch Leerzeilen) die Durchlaufszeit beeinflussen. So auch die Zeilen der Gebundenen Unterprogramme, sofern diese durchlaufen werden.
Soviel ich weiss, kriegt der Submitinterpreter nur jeden zweiten IPO Takt Rechenzeit und dann (so glaube ich) noch weniger als der Roboterinterpreter. Doch 2sec Durchlaufzeit ist sehr gross... poste doch mal dein sps.sub plus alle gebundenen Unterprogramme. Dann kann ich dir genaueres sagen.

hallo

danke für das angebot aber da gibts nichts zu posten ist erstens net auf meinem Mist gewachsen und meine sind schnell genug obwohl einiges drin ist aber halt optimiert.

wollte nur sagen das wenn man den sub zu arg aufbläht sich net wundern muss das der zyklus länger dauert.

schönes WE zusammen

Loipe

Zitat von simeonw

Ich weiss nur, dass jede Zeile im SPS.sub (auch Leerzeilen) die Durchlaufszeit beeinflussen. So auch die Zeilen der Gebundenen Unterprogramme, sofern diese durchlaufen werden.

Hallo,

habe ich mal 7000 Leerzeilen in meine SUB eingefügt und siehe da:
Statt 70 Durchläufe pro Sekunde habe ich dann bloß noch 12-15!

Allerdings habe ich fast 2000 Durchläufe, wenn ich die SUB ohne meinem User-Quellcode laufen lasse.
Aber allein der Eintrag: WAIT FOR $IN[1025] drückt die SUB schon auf 1400 Durchläufe!

Ciao, Andreas

hmm WAIT SEC und WAIT FOR gehören nicht in den Submit! PFUI!

Zitat von simeonw

hmm WAIT SEC und WAIT FOR gehören nicht in den Submit! PFUI!

WAIT FOR $IN[1025] löst kein WAIT aus, weil $IN[1025] ja immer TRUE ist.
Wollte nur testen, wieviel Zeit so eine (erfüllte) WAIT Anweisung benötigt.

Ciao, Andreas

Zitat

WAIT FOR $IN[1025] löst kein WAIT aus, weil $IN[1025] ja immer TRUE ist.
Wollte nur testen, wieviel Zeit so eine (erfüllte) WAIT Anweisung benötigt.

Ist eben nicht so, es wird trotzdem ein minimales Wait durchgeführt, wie du selber feststellen musstest.

Zitat

Allerdings habe ich fast 2000 Durchläufe, wenn ich die SUB ohne meinem User-Quellcode laufen lasse.
Aber allein der Eintrag: WAIT FOR $IN[1025] drückt die SUB schon auf 1400 Durchläufe!

Ich denke mal der Interpreter darf die folgenden Befehle nicht lesen/parsen, bis wirklich sichergestellt ist, dass die Wait For bedingung erfüllt ist. Erst dann darf eigelesen werden und dem Prozessor die weiteren Anweisungen gefüttert werden.

Im übrigen meinte ich das mehr so, dass prinzipiell kein WAIT in den Submit gehört.

Zitat von ah_robotics

In die SUB:
U/s:

Code

$TIMER_STOP[3] = FALSE
  IF $TIMER[3] >= 1000 THEN
    DREHZAHL = q
    $TIMER[3] = 0
    q = 0
  ELSE
    q = q + 1
  ENDIF

DREHZAHL und q dürfen natürlich keine Laufzeitvariablen sein

Was genau ist eine Laufzeitvariable?
Ich wuerde den Drehzahlmesser auch gerne ausprobieren. Was muss noch deklariert werden damit dieser laeuft?

Dankeschoen

ah ok macht alles Sinn. Mir waren diese nur als Local und Global Variables bekannt

Was ist die höchste/niedrigste Drehzahl die ihr so hattet?