Beiträge von rob.target

  • Anstehende Wartungsmeldungen in KRL abfragen

    Hallo liebe Gemeinde,


    hat von euch schon mal jemand herausgefunden, wie man z.B. im Submit-Interpreter anstehende Wartungsmeldungen im Wartungshandbuch der KRC4 ab KSS 8.3 abfragen kann, um diese über eine SPS an übergeordnete Systeme zu melden? Ich würde es der Instandhaltung gerne etwas leichter machen - werden hier bei uns ja auch immer mehr von den Biestern. :lol:


    Besten Gruß

  • BASE Laden

    Hallo, würde auch sagen, dass du die vermessenen Bases zur Laufzeit lädst (ich gehe mal davon aus, dass du die Information, welches Nest gerade bearbeitet werden soll, von einer SPS bekommst):


    ; WARTE AUF ABLEGEN VON SPS
    ...


    ; WARTE AUF FREIGABE BEREICH VON SPS
    ...


    ; FOLD BERECHNUNG


    ; NEST SPEICHERN, DAMIT DER SPS'ler NICHT SAGEN KANN, ER HAETTE DAS RICHTIGE NEST GESCHICKT ;)
    CONTINUE
    DT_NEST = GI_DT_NEST


    CONTINUE
    SWITCH DT_NEST
    CASE 1:
    CONTINUE
    BASE_DATA[7] = BASE_DATA[1]
    CASE 2:
    CONTINUE
    BASE_DATA[7] = BASE_DATA[2]
    CASE 3:
    CONTINUE
    BASE_DATA[7] = BASE_DATA[3]
    CASE 4:
    CONTINUE
    BASE_DATA[7] = BASE_DATA[4]
    CASE 5:
    CONTINUE
    BASE_DATA[7] = BASE_DATA[5]
    CASE 6:
    CONTINUE
    BASE_DATA[7] = BASE_DATA[6]
    DEFAULT
    ;UNGUELTIGES NEST VON SPS
    WAIT FOR FALSE
    ENDSWITCH


    ; ENDFOLD


    ; IN BEREICH ANMELDEN
    ...


    Hat den Vorteil, dass du dann die Punkte alle im Inline-Formular in BASE[7] teachen kannst, nachdem du dieser die entsprechende Base zugewiesen hast. Dein Programm wirkt dann auch schön sauber und ein nicht so geübter Bediener kommt auch noch damit zurecht...


    Schöne Grüße

  • Array in Dat-File

    Hatte ich so bei KRC1, KRC2 und KRC4... Habe mir deshalb die Mühe gemacht und die einzelnen Array-Elemtente im .dat-File angelegt. Dann wird es auch persistiert...
    Beste Grüße

  • Kuka KRC2 / Unzulässiger Feldindex

    Hallo zusammen, ich hatte dieses Problem auch mal. Bei mir lag es an einer falschen Deklaration des Array's.


    Ich hatte das Array wie folgt in einer .dat deklariert:


    DECL INT MY_INT_ARRAY[4]


    Die Lösung war das Array wie folgt zu deklarieren:


    DECL INT MY_INT_ARRAY[4]
    MY_INT_ARRAY[1] = 0
    MY_INT_ARRAY[2] = 0
    MY_INT_ARRAY[3] = 0
    MY_INT_ARRAY[4] = 0


    Vielleicht hilft es...

  • SYNOUT - Problem

    Hallo Titan, vielen Dank für den Tip. :supi:


    Diese Möglichkeit kenne ich natürlich und entscheide mich bewusst dagegen . Das soll in dieser Sache auch nicht zu einer Diskussion führen (Pro/Contra).



    Mir geht es nur um das beschriebene Verhalten. Meine Vermutung ist mittlerweile, dass die Triggerereignisse mit unterschiedlicher Prio in der KRC ausgeführt werden. Zudem haben in diesem Fall die Positionen VOR_BEREICH_1 und AUS_BEREICH_1 die gleichen Koordinaten. Möglicherweise führt das alles in der Steuerung zu einem anderen Verhalten als von mir angenommen und ursprünglich programmiert.


    Zitat von rob.target

    Dabei ist aufgefallen, dass das Signal "DO_FREIGABE_BEREICH_1" bei mehrfachem Aufruf gesetzt bleibt, obwohl dieses so nicht programmiert gewesen ist... :nocheck:


    Das sollte natürlich auch "DO_AUS_BEREICH_1" heißen...

  • SYNOUT - Problem

    Hallo zusammen!
    Anbei eine Frage zum unten stehenden Code. Leider war ich heute Zeuge eines ungewollten Kontaktes zwischen einem Handling und einem KUKA bei einem Traywechsel. Bis auf nen Kratzer ist alles gut gegangen! Flink den Not-Halt gedrückt... :roll:


    Bei einer freien Position in einem Tray rufe ich das selbe Programm so häufig auf, bis ich ein Bauteil gefunden und gegriffen habe.


    Dabei ist aufgefallen, dass das Signal "DO_FREIGABE_BEREICH_1" bei mehrfachem Aufruf gesetzt bleibt, obwohl dieses so nicht programmiert gewesen ist...


    $ADVANCED = 1
    ...
    PTP VOR_BEREICH_1 CONT
    WAIT FOR DI_FREIGABE_BEREICH_1 CONT
    SYNOUT DO_AUS_BEREICH_1 STATE = FALSE AT START DELAY = 0
    ;HIER BAUTEILENTNAHME, WENN BAUTEIL GEFUNDEN...
    SYNOUT DO_AUS_BEREICH_1 STATE = TRUE AT END DELAY = 0
    PTP AUS_BEREICH_1 CONT


    Abhilfe habe ich mir erstmal so geschaffen:


    $ADVANCED = 1
    ...
    PTP VOR_BEREICH_1 CONT
    WAIT FOR DI_FREIGABE_BEREICH_1 CONT
    OUT DO_AUS_BEREICH_1 STATE = FALSE CONT
    ;HIER BAUTEILENTNAHME, WENN BAUTEIL GEFUNDEN...
    PTP AUS_BEREICH_1
    OUT DO_AUS_BEREICH_1 STATE = TRUE


    Funktioniert natürlich... Finde diesen Genauhalt nur nicht sooo schön...
    Jemand eine Erklärung für das Verhalten mit obigen Code? :nocheck:

  • Eine Sekunde Wartezeit bei Genauhalt

    Hallo liebe Gemeinde,


    ich beobachte gerade bei einem KR Agilus (KSS 8.3.15) ein mir nicht erklärbares Verhalten. Bei einem Genauhalt (Aufnahme/Entnahme Bauteil) verweilt der Roboter für ziemlich exakt eine Sekunde. Die Greiferaus- und eingänge werden unmittelbar geschrieben bzw. gelesen. Auch der Handshake zur SPS über Profibus verläuft im Bereich von Millisekunden und somit völlig normal. (Traceaufzeichnungen OK). Selbes Verhalten stellt sich bei jeder angefahrenen Position ein, wenn $ADVANCED = 0 gesetzt wird.


    Gibt es da eventuell eine Systemvariable die dieses Verhalten auslösen kann?


    Oder hat jemand eine andere Vermutung der man nachgehen könnte? :kopfkratz:

  • Abfrage "Smartpad gesteckt"

    Moin zusammen,
    kennt hier jemand eine Möglichkeit abzufragen, ob das Smartpad an der KRC4 gesteckt ist (z.B. über eine Systemvariable)?
    Ein Kunde möchte dies in einer größeren Anlage abgefragt haben.
    Vielen Dank im Voraus!

  • KRC4 Beckhoff EL6695 FSoE Konfiguration

    Hallo zusammen,


    ich greife das Thema nochmal auf. Ich nehme gerade zum ersten Mal einen KUKA an einer Beckhoff in Betrieb.


    Irgendwie habe ich noch grundsätzliche Schwierigkeiten. Beim Scannen aus TC3 heraus findet er die "KUKA secondary EL6695-1001" zwar, allerdings fehlt TC3 die Gerätebeschreibungsdatei (obwohl diese aktualisiert sind - sowie das TC3 auch den letzten Stand hat).


    Es sollen nur 64 Byte Ein-/Ausgangsdaten konfiguriert werden. Sicherheit geht ganz normal über die X11 - ohne FSoE-Objekte. Siehe Konfig WoV...


    Wie schon beschrieben, habe auch ich die Erfahrungen machen müssen, dass Beckhoff auf Kuka verweist und anders herum. Keiner will die Gerätebeschreibungsdatei haben!?


    Was war bei euch des Rätsels Lösung? :kopfkratz:

  • Profinet mit altem KRC2-Roboter Devicenet verbinden

    Check! Genau so... Nur devnet.ini und iosys.ini mit der entsprechenden Byte-Anzahl projektieren und los geht´s. Ich lass eigentlich die Baudrate auf 500kb, weil ich das Gerät auch gerne im KRC direkt einbaue. Ist ja nur die eine Leitung von der MFC runter. Die Projektierung ist dann im Hilscher-Tool ähnlich wie im WorkVisual... :supi:

  • Wait Befehle umgehen so das Roboter nicht stehen bleibt?

    Könnte man auch im Submit machen:


    IF HM_SPANNEN THEN

    DO_SPANNER_1_ZU = TRUE
    DO_SPANNER_1_AUF = FALSE


    ;SPANNER 2 ERST ZU WENN SPANNER 1 ZU
    IF (DI_SPANNER_1_ZU AND NOT DI_SPANNER_1_AUF) THEN
    DO_SPANNER_2_ZU = TRUE
    DO_SPANNER_2_AUF = FALSE
    ENDIF


    ;...


    ELSE


    DO_SPANNER_2_ZU = FALSE
    DO_SPANNER_2_AUF = TRUE


    ;SPANNER 1 ERST AUF WENN SPANNER 2 AUF
    IF (NOT DI_SPANNER_2_ZU AND DI_SPANNER_2_AUF) THEN
    DO_SPANNER_1_ZU = FALSE
    DO_SPANNER_1_AUF = TRUE
    ENDIF


    ;...


    ENDIF


    HM_SPANNEN dann im Bewegungsprogramm über einen Trigger im Unterprogramm auf TRUE oder FALSE setzen...


    Im Bewegungsprogramm dann an den entsprechenden Stellen noch WAIT CONT für die Abfragen der Eingänge programmiert (wenn nötig) und schon wird so einiges parallel abgearbeitet und die Bewegung überschliffen.


    Das freut dann den Sekunden-Hai! ;)

  • Taster zum ein Ausschalten von Ausgängen

    ;DEKLARATION - Z.B. IN DER CONFIG.DAT
    INT ACHSE ; ZAEHLER ACHSE FUER FOR-SCHLEIFE


    ;SCHLEIFE IM SUBMIT
    LOOP


    ; ROBOTER STEHT ERSTMAL AUF TRUE
    HM_ROBOTER_STEHT = TRUE


    FOR ACHSE = 1 TO 6 STEP 1
    IF ($VEL_AXIS_ACT[ACHSE] <> 0.0) THEN
    ;SO LANGE SICH EINE ACHSE BEWEGT
    HM_ROBOTER_STEHT = FALSE
    ENDIF
    ENDFOR


    ; AB HIER DER TUER-KRAM´S...


    ENDLOOP


    Wenn man die Systemvariable nicht nutzen möchte, müsste es auch so gehen... :zwink: :zwink: :zwink: :zwink: :zwink: :zwink: :zwink:

  • Turn T für einen vorgegebenen Frame bestimmen ?

    Hallo,


    du schreibst:


    Es soll aus einer bekannten Grund-Position zu einer Ziel-Position,
    (Daten der Ziel-Position von externen System als Frame via EthernetKRL)
    auf kürzesten Weg gefahren werden.


    Der kürzeste Weg wäre in dem Fall eine Gerade (Lineare Bewegung) aber auch nicht unbedingt der schnellste.
    Da werden Status und Turn nicht ausgewertet - nur bei PTP. Bevor du startest musst du auch eine SAK-Fahrt (z.B. in eine Home-Position) machen (PTP). ;)