Beiträge von Ducky

    Ich bin ja durchaus immer für Eigeninitiative, aber von meinen Robotern dann doch lieber nicht :genau:


    Jedenfalls hat [wEm]s Tip mich auf den richtigen Weg gebracht; ich habe es jetzt im Prinzip so gelöst:


    Code
    IF ($MODE_OP == #EX) AND ($PRO_STATE==#P_STOP) AND (B_AUTOEX == FALSE) AND (B_SWITCH == FALSE) THEN
    B_SWITCH = TRUE
    CWRITE($CMD,STAT,MODE,"CANCEL 1")
    ENDIF
    
    
    IF ($MODE_OP == #EX) AND ($PRO_STATE==#P_FREE) AND (B_AUTOEX == FALSE) THEN
    CWRITE($CMD,STAT,MODE,"RUN /R1/CELL()")
    B_AUTOEX = TRUE
    ENDIF


    Danke für die Hilfe :)

    Hallo,


    ich richte gerade mal wieder einen KUKA (KRC 4) ein und um das Hin- und Herschalten zwischen T1 und EXT etwas komfortabler zu gestalten habe ich folgende Routine in sps.sub eingefügt:


    Der Plan war, dass ein von mir in T1 angewähltes Unterprogramm automatisch beendet und dann cell angewählt wird wenn ich in Extern umschalte. Das funktioniert auch soweit. Nur: Wenn ich in den externen Modus umschalte und zuvor ein Programm angewählt hatte startet cell automatisch, obwohl von der SPS definitiv kein Startsignal kommt. Das passiert, unabhängig ob das Programm noch am Anfang stand, pausiert ist oder durchgelaufen ist. Das kann doch nicht so gewollt sein?


    Wenn cell mit cwrite aktiviert wird ohne dass vorher ein Programm angewählt war passiert das nicht, d.h. der Roboter wartet brav auf sein Startsignal; ich habe die Routine erst mal wieder auf den Fall ($PRO_STATE1 == #P_FREE) beschränkt.


    Gibt es eine Möglichkeit, das automatische Abwählen von Programmen 'sicher' zu machen, also zu verhindern dass der Roboter direkt loslegen will?

    Hallo,


    ich programmiere gerade an einem Palettierprojekt und habe/hatte ein Problem mit dem Überschleifen von Punkten. Der Roboter soll ein Bauteil von einer Palette aufnehmen und dann in der ersten Bearbeitungsstation ablegen. Das Aufnehmen von der Palette habe ich mit Positionen in Arrays gelöst; es traten auch keine Probleme auf.


    Beim Probefahren der geteachten Bahn zur Bearbeitungsstation bekam ich dann allerdings bei jeder Position die Meldung "Überschleifen nicht möglich", ohne Angabe einer Fehlernummer. Andere Module auf dem gleichen Roboter ließen sich tadellos (mit Überschleifen) fahren und beim Durchforsten der PDATs, FDATs usw. sind mir keine Unterschiede aufgefallen.


    Ich habe das Problem vorerst gelöst indem ich die Bewegungen des Roboters nach dem Aufnehmen in ein neues Modul geschrieben habe, das ich dann vom ursprünglichen Modul aufrufen will. Hier auch keine Probleme beim Überschleifen.


    Ich war dann mal neugierig und habe den gesamten Quelltext des neuen Moduls ins alte kopiert (mit unterschiedlichen Variablennamen) - siehe da, Überschleifen ging wieder nicht.


    Kann es daran liegen dass das DAT File des ursprünglichen Moduls sehr mit Positionen vollgepackt ist? Die Paletten sind ganz schön dicht bepackt; im Moment bin ich bei ca 400 E6POSs.... :denk:

    Versuchs mal mit einer while- oder repeat-Schleife, mit einer IF-ELSE Fallunterscheidung. Im Prinzip folgendermaßen:


    Zähler = 1
    WHILE: Zähler <=5
    IF blau THEN
    bearbeiteBlauesTeil()
    ELSE
    bearbeiteRotesTeil(Zähler)
    Zähler ++
    ENDIF
    ENDWHILE


    EDIT: ...also so wie bei Martl, nur in schreibfaul ^^;

    Nein, ich meinte dass der Robi erst vom Hauptprogramm in die entsprechende Position gefahren wird, dann wird mit CALL ein neuer Job aufgerufen, und zu Beginn dieses Jobs wird die Position erst mal überprüft. Sozusagen um sicherzustellen dass der Job auch zum richtigen Zeitpunkt aufgerufen wurde.


    Aber zu deinem Vorschlag, was genau würde ich mit der eingelesenen aktuellen Position machen? Soweit ich weiß kann ich dem Roboter einfach die Anweisung geben, nach Hause zu fahren, egal wo er ist. Gibt es da mit der Positionsabfrage einen Trick, damit er etwas kontrollierter in die Startposition fährt als einfach gnadenlos auf direktem Wege?

    Hallo,


    ich habe die Situation dass ich eine größere Anzahl von Handlingjobs programmieren möchte, die allerdings größtenteils Kombinationen einiger weniger Bewegungsabläufe sind. Um mein Programm übersichtlich zu halten, und das Kopieren von Quelltext zu vermeiden würde ich diese Bewegungen gerne in einzelne Jobs aufteilen und dann gegebenenfalls mit CALL aufrufen.


    Allerdings würden diese CALL-Jobs teilweise in sehr beengten Verhältnissen beginnen und enden. Wenn der Roboter beim Aufruf also nicht auf genau der richtigen Startposition steht würde es teuer krachen. Ist im normalen, fehlerfreien Ablauf kein Problem, aber was läuft schon immer fehlerfrei? Ich hatte überlegt am Anfang jedes dieser CALL-Jobs einen Cube-Ausgang abzufragen; ist der TCP nicht im (sehr kleinen) Cube bewegt sich erst mal nichts.


    Was meint ihr? Mache ich mir zu viele Gedanken und das Programm unnötig kompliziert? Gibt es noch andere Möglichkeiten solche Situationen abzusichern?


    Würde mich über Meinungen freuen :)

    Ich muss mich leider outen, ich habe die Erklärung auch nicht ganz verstanden :nocheck:


    Blauer, könntest du das ein wenig genauer erklären? Ist das Aufnehmen von Screenshots grundsätzlich möglich oder muss es erst freigeschaltet werden? Und wie genau gehe ich vor, auch und vor allem im normalen Programmier/Erweiterten Modus? Einfach AUX und Area zusammen drücken habe ich ausprobiert, auch mit eingelegtem Datenträger, da kam nichts.


    Und, auf die Gefahr hin dass das Allgemeinwissen ist, was und wo ist diese YIF?


    :danke:

    Hallo,


    anlässlich einer Handlingaufgabe mit einem KUKA-Roboter steht gerade die Frage im Raum, ob das Technologiepaket Gripper&SpotTech angeschafft werden soll. Leider konnte ich auf kuka-robotics keine Angaben dazu finden was dieses Paket nun konkret enthält (bis auf Befehle zum Punktschweißen, und die werden definitiv nicht benötigt).


    Welche Handling-bezogenen Befehle sind in diesem Paket drin, und gibt es Meinungen ob sich die Anschaffung lohnt?


    Schonmal Danke im Voraus :merci:

    Hi,


    was mir spontan einfällt ist ein Umrechnen per Schleife (und ich bitte um Nachsicht bei Fehlern, der Programmtext ist komplett ungetestet):


    SET LB000 32768 //(also 2^15)
    SET LD000 D000 //Dein Eingangswert und neuer Ausgangswert LowByte
    SET LD001 0 //Neuer Ausgangswert HighByte


    FOR I000 8 to 15
    IF D000 >= LB000
    SUB D000 LB000
    ADD LD001 LB000
    ENDIF
    DIV LB000 2
    NEXT I000


    DIV LD001 256


    Ist nicht besonders elegant aber es sollte erstmal funktionieren. Mach dir am besten ein Makro draus, dann ist es auch noch halbwegs komfortabel zu benutzen.

    Hi, und sorry für die späte Antwort :oops:


    Das Problem sind weniger die Anzahl der Punkte; die Bewegungsabläufe sind immer die gleichen. Die angefahrenen Punkte müssen aber je nach ausgewähltem Werkzeug angepasst werden, je nach Durchmesser, Höhe, Höhe der Werkstückaufnahme, Durchmesser der Bohrlochkreise, etc. Der Plan war, bei einem Wechsel des Werkstücktyps die Referenzpunkte der Bewegung mit den werkstückspezifischen Variablen anzupassen (durch Addieren).


    Fürs erste bin ich zum Glück auch ohne externes Speichern ausgekommen; ich musste nicht so viele WS-Eigenschaften speichern wie benötigt und den Rest konnte ich halbwegs komprimieren. Aber trotzdem Danke für den Tip mit X,Y,Z-Daten via SPS lagern. Werde ich mir für die Zukunft merken :gutidee:

    Ist es möglich, die Externes Laden/Sichern Funktion des Motoman Roboters von der SPS aus anzusteuern?


    Ich habe nämlich das Problem, dass eine Anwendung flexibel für eine größere Anzahl von Werkstücken verwendet werden kann. Und je nachdem wie viele Variablen pro Bauteil da zusammen kommen (das muss noch getestet werden) werden mir die Speicherplätze für P Variablen knapp. Eine Reihe von VAR.dat Dateien die jeweils die allgemein gültigen Variablen und eine Anzahl von bauteilspezifischen Variablen für eine Anzahl Werkstücke auf einer Compact Flash zu speichern und bei Bedarf aufzuspielen wäre m.E. eine Möglichkeit. Aber ich möchte dem Endnutzer ungern zumuten, das für jeden Werkstückwechsel per Hand durchzuführen. Gibt es da einen komfortablen Weg, das per SPS zu machen?


    Schonmal Danke im Voraus

    Hallo zusammen,


    ich habe eine Frage zum Thema sicheres Beenden eines Roboter-Jobs. Ich möchte - in erster Linie zum Debuggen - einen Job schreiben mit dem ich eine Fehlernummer an eine Ausgangsgruppe übergeben und den Roboter sicher zum Anhalten bringen kann.


    Im Moment sieht der Job so aus:


    NOP
    GETARG(1) LB000
    DOUT OG# LB000
    PAUSE
    END


    Leider steht in meinen Unterlagen nichts dazu bis zu welchem Ereignis der pause-Befehl wirkt. Ist er für diesen Zweck geeignet? Oder wäre abort (zu dem ich überhaupt nichts näheres gefunden habe) besser? :hilfe: