Posts by rob.target

    Hallo liebe Gemeinde,


    da ich selber nicht auf ADEPT fit bin, wir aber in unserem Betrieb eine Bestandsanlage laufen haben, an welcher relativ zeitnah Programmänderungen vorgenommen werden sollen, starte ich hier mal eine Anfrage.


    Die Applikation beschränkt sich auf reine Handlingsaufgaben, wobei einem bestehendem Programm ein weiteres Produkt hinzugefügt werden soll.

    Es hadelt sich um einen Viper s1300 an einem SmartController CX. Gesteuert wird die Zelle von einer Beckhoff TC2, die Kommunikation läuft über CAN.

    Bei Interesse an einem Auftrag bitte eine PN. Alles weitere kann dann im Nachgang besprochen werden.


    Vielen Dank im Voraus


    rob.target

    Hallo zusammen,


    vielen Dank für die Antworten! :supi:


    Die Systemsignale habe ich gefunden und die ProfiNet-Signale entsprechend konfiguriert:


    GP_bool_in[0] => Starten des aktuellen Programms

    GP_bool_in[1] => Stoppen des aktuellen Programms

    GP_bool_in[2] => Unterbrechen des aktuellen Programms

    GP_bool_in[3] => Freedrive

    GP_bool_in[4] => Autostarten des Standardprogramms im Programm-Ausführen-Fenster

    GP_bool_in[5] => Automatische Bremsenfreigabe des Roboters


    GP_bool_out[0] => Ausgang ist LOW, wenn nicht aktiv : LOW, wenn der Programmzustand „gestoppt” oder „unterbrochen” ist.

    GP_bool_out[1] => HIGH, wenn nicht aktiv : Ausgang ist HIGH, wenn der Programmzustand „gestoppt” oder „unterbrochen” ist.

    GP_bool_out[2] => HIGH, wenn aktiv. LOW, wenn gestoppt. : Ausgang ist LOW, wenn der Programmzustand „gestoppt” oder „unterbrochen” ist und HIGH, wenn aktiv.


    Dann habe ich ich noch noch den State des UR als INT im Prozessabbild:


    0 = Disconnected

    1 = Confirm_safety

    2 = Booting

    3 = Power_off

    4 = Power_on

    5 = Idle

    6 = Backdrive

    7 = Running


    Und diverse Statusbits auch:


    AOM = Analog output mask

    AOT = Analog output types

    ES = Is emergency stopped

    FT = Is fault

    NO = Is normal mode

    PB = Is power button pressed

    PR = Is program running

    PS = Is protective stopped

    PW = Is power on

    RC = Is recovery mode

    RD = Is reduced mode

    RES = Is robot emergency stopped

    SES = Is system emergency stopped

    SS = Is safeguard stopped

    SSM = Speed slider fraction mask

    ST = Is stopped due to safety

    TAIT = Tool analog input types

    TB = Is teach button pressed

    TDI = Tool digital inputs

    TDO = Tool digital outputs

    TDOM = Tool digital output mask

    VL=Is violation


    Jetzt ist es so, dass ich mittlerweile den Roboter von der SPS aus starten kann, nur eben nicht zuverlässig, wie ich es z.B. von einem KUKA, ABB oder Kawasaki gewohnt bin. Da gibt es in der Doku z.B. solche Diagramme:



    Daher meine Frage, wie ein zuverlässiges Handshaking mit welchen Signalen aussieht, um den UR zu starten?


    Nach dem Einschalten, Initialisieren und Starten des Standardprogramms, bleibt mir der Kleine nämlich häufig stehen - sprich, das Standardprogramm bleibt gestoppt. Ist es dann doch mal gestartet gewesen, dann lässt sich dieses auch stoppen,unterbrechen und auch wieder anstarten.:kopfkratz:


    Den Dashboard-Server würde ich gerne meiden wollen und die Unterprogrammanwahl wie gewohnt und bewährt über eine Switch/Case- Anweisung realisieren.


    Beste Grüße in die Runde...

    Vielen Dank für den Tipp!


    Meine Vermutung hat sich bestätigt. Beim Austausch der Getriebe ist das der A6 verwechselt worden. Der Sevice-Mitarbeiter hatte im ersten Anlauf versehentlich das Getriebe für einen KR10 eingebaut. Daher auch das beschriebene Verhalten. Nach dem heutigen Einbau des richtigen Ersatzteils, lief der Kleine wieder wie am Schnürchen...


    Beste Grüße

    Hallo zusammen,


    ich wurde hier gerade zu einem Problem gerufen. Nach einem Getriebetausch der A5+A6 des besagten Roboters inkl. neu durchgeführter und überprüfter Justage usw. verhält sich dieser ziemlich merkwürdig.


    Spirch, er bleibt z.B. beim kartesischen Handverfahren in Z (WORLD, BASE = $NULLFRAME, TOOL = $NULLFRAME) nicht auf der Bahn und die Orientierung des Werkzeuges ändert sich. Beim Verfahren im Tool-KS liegt der TCP nicht mehr dort wo er eigentlich sein sollte und orientiert um irgendeinen TCP, nur nicht dem eingetragenen.


    Ich habe nochmal die Maschinendaten überprüft - diese passen augenscheinlich.


    Gibt es bei der Serie unterschiedliche Getriebe, sodass es beim Austausch zu einer Verwechslung gekommen ist (Vermutung)?


    Mit was für einem Problem könnte ich es hier zu tun haben? Jemand eine Idee? Ich bin doch nur Programmierer... :uglyhammer_2:


    Beste Grüße

    Gibt es eine SPS als Master? Oder können die Roboter über diskrete Signale miteinander "sprechen"?


    Dann wäre mein Vorschlag über Bereichsanforderungen und -freigaben zu arbeiten (Pseudocode):


    OUT DO_ANF_BEREICH_1 = TRUE
    WAIT DI_FRG_BEREICH_1 = TRUE
    OUT DO_AUS_BEREICH_1 = FALSE
    .
    .
    Fahre in Bereich
    .
    .
    Mache etwas
    .
    .
    Fahre aus Bereich
    .
    .
    OUT DO_ANF_BEREICH_1 = FALSE
    WAIT DI_FRG_BEREICH_1 = FALSE
    OUT DO_AUS_BEREICH_1 = TRUE


    Bei einer HOME-Fahrt nicht vergessen alle ANF_BEREICH_X = FALSE und AUS_BEREICH_X = TRUE

    Hallo, liebe Gemeinde!


    Da ich in sehr naher Zukunft einen UR programmieren darf und diesen auch von einer SPS aus starten soll (vgl. KUKA AUT_EXT), wollte ich mich hier im Forum einmal schlau machen, wie man dies am dümmsten umsetzt.


    Gibt es da ein bewährtes Rezept? Ganz schlau bin ich aus der Doku noch nicht geworden. :denk:


    Vorab habe ich allerdings die Kommunikation über Profinet an einer Beckhoff- SPS zum Laufen gebracht...


    Vielen Dank im Voraus

    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ß

    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

    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

    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...

    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.


    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...

    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:

    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:

    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!