KRC4 Zykluszeit ermitteln?

dafuer nutzt man timers...

$TIMER[64]=0 ; zeit zuruecksettzen
$TIMER_STOP[64]=FALSE ; timer loslaufen lasen


TEST_PROG()  ; wasimmer....


$TIMER_START[64]=TRUE ; timer anhalten
MsgNotify("Programm dauerte %1 ms","PANIC",$TIMER[64])

Hallo,

Zitat

$TIMER_START[64]=TRUE ; timer anhalten

sollte eher $TIMER_STOP[64]=TRUE heissen. Ansonsten würde ich auf alle Fälle nach $TIMER[64]=0 und vor $TIMER_STOP[64]=TRUE noch einen Vorlaufstop z.b. über WAIT FOR TRUE einfügen. Ansonsten startet der Timer bereits zu früh im Vorlauf und wird auch zu früh vom Vorlauf wieder beendet.

Fubini

Dafür musst du dann wohl erst einmal deine Buskonfiguration überprüfen. Bei einer Profibus Konfiguration ist beispielsweise ein Watchdog von 30ms eingestellt. Somit sollten zumindest über den Bus alle 30ms Daten über den Bus eintrudeln. Das hat aber weniger mit der KRC4 zu tun als mit der Buskonfiguration. Die ist genormt.

Und so wie ich es verstanden habe, sollten nach dem Empfang der Daten diese auch zur Verabeitung bereit stehen.

Ansonsten:

Ein Produkt mit unterschiedlichen Geschwindigkeiten suchen lassen und die Ergebnisse vergleichen. Daraus kannst du dann auch Rückschlüsse über die Geschwindigkeit der Verabeitungskette ziehen.

es gibt noch extra schnelle Eingänge ....

diese werde ich glaube ich direct an die Steuerung angeschlossen

Das wird interessant.

der IPOS Takt des Roboters liegt bei 12ms. Schneller wird es nicht.
Langsamer kann es sehr wohl werden, wenn z.B. viel Rechenleistung gebraucht wird (Beispiel: Roboter mit komplexer Bahnplanung, Visiontech, Proconos und Zenon, da geht er schon schnell in die Knie).

Eine Idee wären Interrupts, aber da "normale" EA vermutlich auch nur im IPOS-Takt erfasst werden wird es auch nicht schneller.

Wenn Du einen Roboter da hättest, könntest Du die Zykluszeit des Submitinterpreters messen (Timer wäre hier möglich! - schon beschrieben).
Speichere Dir aber immer nur den MAX-Wert, weil Du es sonst nicht schnellgenug angezeigt bekommst. Messen kannst Du dann mal in jeder
Lebenslage... Stillstand, Bewegung, viel Kommunikation, etc.

Beschreib doch mal genauer was "Suchen mit Sensoren ist" - vllt. gibt es weitere Ansätze.

Ggf. ist ein Vorlaufstop gar nicht gewuenscht, wenn eine die zeit fuers messen ermittelt werden soll.

Ich wuerde den timer beim losfahren starten (trigger when distance = 0...).

Anhalten in der Interrupt Routine - da sollte Satzvorlauf keine Rolle spielen.

Ich gehe mal davon aus, das Interupts verwendet werden, sonar kann man sich schnelle eingaenge eh sparen.

BTW, bei KRC2 war das ein Appel und ein Ei - KRC4 soviel teurer?

Gesendet von meinem HTC_Butterfly_s_901s mit Tapatalk

Die 12ms ipo takt sollten schon verlaesslich sein.
Roboterinterpreter wird hoffentlich mit hoeherer prio laufen als soft sps.
Kann aber durch andere interrupts (oder Bahnschaltfunktionen) mit hoehere prio verzoegert werden.

Die 12ms oder 400 micro sekunden sind ein guter Anhaltspunkt.
Mit der geschindigkeit gibt das die ideale aufloessung wieder.

Gesendet von meinem HTC_Butterfly_s_901s mit Tapatalk

Guten Morgen,

sps.sub ist nicht zuverlässig 12ms. Gestern mal mit 2 Timern ausprobiert, die max. Zykluszeit krieg ich nicht kleiner als 48ms. Auch wenn ich den Timer von Hand abnulle steht sofort wieder 48 drin - es scheint also oft "48er-Zyklen" zu geben. Mit ein paar mehr E/As in der Verarbeitung (aber immer noch nicht viele) gings ganz schnell auch mal auf 60ms hoch...

Gruß,
Robotermann

Wenn es nur um wenig KRL-Code geht, der schneller als 48ms bearbeitet werden muss,
gibt es einen Trick der mit der KRC funktioniert:

Du brauchst dazu nur auf deiner Busverbindung zwischen SPS & KRC in jede Richtung ein
binäres Signal:

SPS:
bOutCyclicToggle:=NOT bInCyclicToggle;

KRC:
Im Signal-Mapping das Signal von der SPS direkt auf das Signal an die SPS verknüpfen.
(Wichtig, dies MUSS im Verschaltungseditor geschehen, NICHT im Submit-Interpreter!).
Ausserdem das Signal auf eine $IN Variable legen.

Dies Konstellation führt dazu, dass das Signal im Buszyklus toggelt, wobei bei meinen Tests
nie Toggle-Zeiten kleiner IPO-Takt resultierten.

Nun deklarierst du dir 2 globale Interrupts, beide auf das gleiche Signal, einmal jedoch mit
einer fallenden, einmal mit einer steigenden Flanke. Beide Interrupts verknüpfst du mit dem
gleichen Programm, in das du die Zeilen aus deiner SPS.SUB kopierst mit denen du Istwerte
auf OUT-Signale der Busverbindung kopierst. Den Code in der SPS.SUB würde ich dennoch
stehen lassen. Was noch Sinn macht, ist eine weitere Ausgangsvariable in dem Interrupt-
Code zu ergänzen, die dort auch einfach bei jedem Aufruf getoggelt wird. So hast du eine
perfekte Möglichkeit um zu Messen, mit welcher Frequenz dein Interrupt-Code tatsächlich
bearbeitet wird. In meinem Fall waren dies absolut zuverlässig 12ms. (Aufgezeichnet mit
mit dem Software-Scope der SPS).

Mit diesem simplen Trick, den ich bisher bei 2 Anlagen umgesetzt habe, war es zuverlässig
möglich die Istwerte im 12ms Takt aus der KRC zu bekommen. Setzte dies beispielsweise ein,
um eine externe Servoachse auf den Roboter zu synchronisieren. Klappt tadellos.

Gruss, Peter

PS: Mit ProConOS lässt sich auch zyklisch die Istposition abgreifen, aber das Produkt ist völlig
überteuert, dito dessen Programmiertool. Ausserdem ist es unter den SPS'en was Flexibilität,
Schnittstellen, und Einsatmöglichkeiten angeht das schlechteste Produkt mit dem ich in den
vergangenen 15 Jahren je arbeiten musste.