SIGNAL-name als parameter?

    moin moin


    ich hab ein kleines programm geschrieben, das den "WAIT FOR" ersetzen soll. es tut eine bestimmte zeit einen eingang auf einen bestimmten wert abfragen und bei misserfolg definierbar reagieren:



    soweitsogut. nur würde ich den "input" gerne name übergeben anstatt als INT. halt genau so, wie er im $config.dat als SIGNAL deklariert wurde. ist das irgendwie möglich :kopfkratz:


    besten dank!

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    • Schritt für Schritt zum Roboterprofi!

    Sers,


    ich wuerd mir Konstanten mit den Zahlenwerten, wenn Dein Signal z.B. DI_GripperClosed heisst und auf Eingang 3 liegt, dann wuerd ich mir ne Konstante machen die IC_GripperClosed die den Wert 3 hat.
    Du kannst natuerlich auch den Namen als String uebergeben, dann muss aber Dein Programm alle moeglichen Namen kennen, dadurch ist es nicht mehr so leicht zu haendeln, und die wieder Verwendtbarkeit laesst auch zu wuenschen uebrig.


    Gruss Elias

    IF ROBOTER_STEHT AND SPS_VORHANDEN THEN<br />&nbsp; WHILE NOT ROBOTER_LAEUFT<br />&nbsp; &nbsp; &nbsp; $LOOP_MSG[]=&quot;SPS IST SCHULD!&quot;<br />&nbsp; ENDWHILE<br />&nbsp; $LOOP_MSG[]=&quot;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;<br />ENDIF<br /><br />Geld ohne Arbeit! Keine Arbeit ohne Geld!

    jo, daran dachte ich auch, nur eben, das sieht nach viel doppelter arbeit aus. ich hab nochmal das programmierbuch durchgeackert und die lösung gefunden. mit "GET_SIG_INF( "SIGNAL-name" ) lässt sich so einiges über SIGNALe in erfahrung bringen (programmierung_experte -> digitale_ein-/ausgänge -> signalnummern_auslesen):


    sig_inf.IDX ist dann direkt die zugewiesene SIGNAL-nummer. aufrufen lässt sich das so (vorausgesetzt dass die ENUMs PROG_ERRTXT, REACTION und das programm ERROR_HANDLER( ... ) irgendwo definiert sind:


    ...wartet 5 sekunden auf "greifer geschlossen"-sensor. falls das nicht klappt wird der fehler #CANT_CLOSE_GRIPPER dem error_handler() übermittelt (der leitet das weiter an die SPS, welche die fehlermeldung auf den bildschirm schreibt). #PERSIST macht dann, dass das programm erst weitermacht, wenn der fehler behoben ist.


    naja: $TIMER[4]... für die TIMER muss ich unbedingt noch konstanten anlegen... $TIMER[tAwait] wär schon viel besser...


    gruss, rob

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    Einmal editiert, zuletzt von rob ()

    geht klar. wollt ich sowieso tun, hab nur grad recht wenig zeit.

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    Sers,


    cool! Ich kannte diese Funktion nicht und hab deshalb auch nochmal in den Handbuechern nachgeschaut, habs allerdings nur in den Handbuechern fuer SW 5.x gefunden. Gibts das erst seit 5.x oder ist das bei 4.x bloss nicht dokumentiert??


    Gruss Elias

    IF ROBOTER_STEHT AND SPS_VORHANDEN THEN<br />&nbsp; WHILE NOT ROBOTER_LAEUFT<br />&nbsp; &nbsp; &nbsp; $LOOP_MSG[]=&quot;SPS IST SCHULD!&quot;<br />&nbsp; ENDWHILE<br />&nbsp; $LOOP_MSG[]=&quot;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;<br />ENDIF<br /><br />Geld ohne Arbeit! Keine Arbeit ohne Geld!

    gute frage. ich seh's auch nur im 5.x. witzig: es steht nicht in den neuheiten. müsste fast jemand ausprobieren, ob das schon früher geht. ich hab im moment leider nur zugriff auf 5.2 (officelite).

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    hab einen kleinen performance vergleich gemacht, wobei es bei VARSTATE und SIGINF durch das nichtvorhandensein der abgefragten variablen vermutlich eher schlechte werte sind:


    ...das ganze liess ich dann auf einem PIV 3.0 OfficeLite 5.2.0 drei mal laufen. die reproduzierbarkeit ist gut:

    Code
    durchgang                       1              2                3
--------------------------------------------------------------
counter                   :   7032ms    7044ms    7032ms
counter + VARSTATE : 71244ms  71256ms  71256ms
counter + SIGINF     : 26928ms  26916ms  27000ms


    müsste man noch durch eine million dividieren. bin grad zu faul :liebe029:
    => SIGINF ist nur etwa ein drittel so übel wie VARSTATE :genau::uglyhammer_2:
    Gruss

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    Einmal editiert, zuletzt von rob ()

    Das irritiert ein wenig, weil es sich nicht mit meiner Beobachtung deckt. 0,7ms für einen VARSTATE-Aufruf wären ja super, ich hatte innerhalb eines SPS-Programms Werte >10ms beobachtet, allerdings nicht so fein getestet wie Du. Werde das morgen mal probieren, bei der Arbeit.

    If you and DEAD people can read Hex, how many people can read Hex?

    achtung. ich hab das auf einem (vor einem jahr noch) sehr schnellen pentium 4 3.0 mit OfficeLite ermittelt. ich glaube das wären sogar nur 0.07ms (und die zeit vom "counter-test" (runtime "endless") ist ja auch noch nicht abgezogen). das verhältnis lässt sich vielleicht etwa abschätzen, aber nicht, wie lange die funktionen wirklich auf einem roboter laufen.


    wenn die variablen existieren (keine fakes) komm ich sogar auf:
    VARSTATE: 64656ms / 1000000
    SIGINF: 24528ms / 1000000


    ausserdem weiss ich nicht, ob die Funktionen tatsächlich bei jedem schleifendurchlauf ausgeführt werden, oder ob's da so'ne art cache gibt (ich denk ma nich).


    naja. ich werd's morgen mal auf einem richtigen roboter testen.


    hattest du denn eine SPS gesamtzykluszeit von 10ms, oder eine verbesserung um 10ms bei weglassen von VARSTATE?

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    Einmal editiert, zuletzt von rob ()

    Ich hab in der SPS ne Routine, die in regelmässigen Abständen Daten an den seriellen Port sendet. Nachdem ich mehrere VARSTATE-Aufrufe (Ich meine es wären 3 gewesen) zu einem zusammengefasst hab (in der Hoffnung, das die anderen auszulesenden Variablen dann auch gesetzt sind) , verbesserte sich die Zeit um etwa 25-30ms.
    Schwer zu sagen, wie lange da ein einzelner Aufruf braucht.

    If you and DEAD people can read Hex, how many people can read Hex?

    Oh, hab in dem oben zitierten Thread ne viel grössere Zeit angegeben. Glaubt eher mal dem, da scheine ich mich beschönigend zu erinnern. Hatte heute leider keine Zeit das mal genauer zu untersuchen.

    If you and DEAD people can read Hex, how many people can read Hex?

    P4 3.0 OfficeLite V5.2 KR100comp V5.2
    --------------------------------------------------------------------------------------
    .src: counter : 0.007036ms 0.0444ms
    .src: counter + VARSTATE : 0.071252ms 2.0940ms
    .src: counter + SIGINF : 0.026948ms 0.1200ms


    .sub: counter : 0.10344ms --
    .sub: counter + VARSTATE : 0.39660ms --
    .sub: loop im loop VARSTATE : 0.32292ms --


    also. der richtige KUKA ist zwischen 4.45x und 29.39x langsamer als der P4 mit officeLite.


    .sub counter + VARSTATE: zähler und VARSTATE im normalen LOOP des SPS.sub.


    .sub loop im loop ... : zähler + VARSTATE in einem WHILE im main-LOOP des SPS.sub (was natürlich völlig absurd ist...).


    interessant ist wie viel länger alles im SPS.sub dauert. Das kommt vermutlich daher, dass es vermutlich ein parallelprozess mit etwas weniger priorität ist. schlussendlich muss man wohl einfach probieren, ob die zeit reicht. :genau:

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    Ja, irgendwo in der Doku steht, das die SPS nicht echtzeitfähig ist und die Ausgänge dadurch eine Reaktionszeit von bis zu 50ms haben. Aber das ist ja nun ne WIRKLICH deutlich langsamere Abbarbeitung!
    Vielen Dank für die Auswertung!
    :danke:


    Wobei die noch nicht meinen extremen Geschwindigkeitszuwachs erklärt, was anderes hatte ich damals nicht geändert...

    If you and DEAD people can read Hex, how many people can read Hex?

    doch doch. ich hatte keine zeit, das .sub auch noch am roboter zu testen. aber wenn du die faktoren anschaust und das hochrechnest geht's schon auf:


    faktoren .src -> .sub
    --------------------------
    counter: 14.7 counter+VARSTATE: 5.5 counter+SIGINF: 11.98


    faktoren PC -> roboter
    -----------------------------
    counter: 6.31 counter+VARSTATE: 29.39 counter+SIGINF: 4.45


    VARSTATE(roboter.SPS.sub) aus .src -> .sub: 2.094ms x 5.5 = 11.517ms
    VARSTATE(roboter.SPS.sub) aus PC->roboter: 0.3966 x 29.39 = 11.656ms


    ...erstaunlich nahe beieinander, die zwei berechnungen :supi: bei zwei aufrufen wären das etwa 23ms ersparnis. und "mein" roboter ist frisch aus der schachtel. wenn deiner noch nen etwas langsameren prozessor hat (noch langsamer :roll:), sind deine 25-30ms schon klar.


    schönes WE :beerchug:


    ...hatt ich noch vergessen. nicht erklären konnte ich mir, dass die funktionen mit vorhandenen variablen auf officeLite schnelle abliefen, auf dem KUKA jedoch langsamer(?). die 23ms sind also eher schnell, weil ich die "fake-variablen" genommen hab...

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    Einmal editiert, zuletzt von rob ()

    Zu Deiner letzten Bemerkung: Das könnte am Zusammenspiel von VXworks und Windows liegen. Ich weiss nicht wirklich, wie die beiden zusammenarbeiten (also wer den Interpreter laufen lässt und wer die Befehle tatsächlich ausführt etc) aber bei officeLite fehlt VXworks doch, oder?

    If you and DEAD people can read Hex, how many people can read Hex?

    so wie ich das sehe ist officeLite und KUKA eigentlich bis auf das fehlen des arms identisch. jedenfalls kann ich beim officeLite PC ein telnet auf 192.0.1.1 machen und bekomm so ne konsole. mit "version" schreibt er mir dann:


    VxWorks (for VxWin RT) version 5.4.2.
    (...)


    oberhand hat wahrscheinlich immer windows. sonst würde die kiste glaub ich nicht abschmieren wenn man USB aktiviert und nen stick 'reindrückt.


    bei bosch war VxWorks der master. da war das (USB) laut einem kollegen kein problem. stäubli ist da konsequenter mit nur noch VxWorks.

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

    Hallo,


    dazu etwas Background-Info: das Roboter-Kernsystem läuft auf einem 3 ms (wenn älter) oder 2 ms (wenn neuer) Ticker. Das heisst ein IPO-Zyklus mit 12 ms wird entweder in 4 oder 6 Teilzyklen unterbrochen. Es gibt im System zwei Sprach-Interpreter, der fürs Roboter-(KRL)-Programm und der für den SPS.SUB - das Verhältnis dabei 3:1, wobei ein Tick Pause gemacht wird.


    Also: in 24 ms kommt dreimal das Roboterprogramm an die Reihe und 1 mal der SPS.SUB - aber nur solange, bis der nächste Ticker kommt (nach 3/2 ms). Wieviele Code-Zeilen des SPS.SUB dabei abgearbeitet werden, kann man eigentlich nicht vorhersagen - jedenfalls ist eine Abtastung von Signalen < 50 ms ziemlicher Unfug.


    Ahja, GET_SIG_INF() gibts erst ab R5


    marvin
    Aus dem Grund soll man unbedingt jede Anweisung im SPS.SUB vermeiden, die irgendwie wartet, dafür dann eine State-Machine oder $timer verwenden.

    das ist interessant. um alles genau voraussehen zu können bräuchte man die disassemblierung und müsste die ticks pro befehl wissen. aber ausprobieren reicht ja völlig. (naja... "genau voraussehen"... bloss nie acrobat starten oder einen usb stick reinschieben... :roll:)


    marvin, weiss du auch wie die call by value übergabe von arrays funktioniert? ich hatte das da mal angesprochen:


    http://www.roboterforum.de/rob…um/index.php?topic=1367.0


    strenggenommen dürfte das doch gar nicht gehen...


    gruss, rob

    &quot;When using vi the screen of your terminal acts as a window into the file which you are editing. Changes which you make to the file are reflected in what you see.&quot;<br />Bill Joy 1978

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden