Beiträge von Maverick

    Programmiersklave vielen Dank für die Antwort. Hat mir echt weiter geholfen und war auch hilfreich.
    Habe alle Punkte mit ConfJ und ConfL super anfahren können, doch habe ich hier ein großes Problem gehabt.
    Das Programm ist leider so flexibel, das ich von jeder Stellung und noch mehr anderen Stellung starte und auch überall enden könnte. Deshalb läuft das über ein kleines Programm mit temporären Positionen, Basen und Werkzeugen, welches ich aber vorher immer mit Daten füttere ;).

    Außerdem sind die Positionen auch noch variabel.


    Es kam dadurch manchmal dazu, dass ich bei einem durchlauf die Vorposition mit ConfJ anfahren musste, aber andere Vorpositionen, beim nächsten durchlauf des Programms (gleiche Zeile, aber veränderte Positionsvariable) nicht. So wollte der Roboter manchmal einfach komplett über sich her fahren, anstelle den Weg außen rum zu nehmen ^^ . So gab es mehrere Situationen.


    Lange Rede kurzer Sinn. Ruder zurück, Schnell die Punkte mit ConfL angefahren, Teachpositionen in den einzelnen Werkobjekten integriert, welche ich dann einfach direkt in die temporären Variablen schiebe, falls benötigt, und dann gehe ich mit einem guten gewissen weiter. Das andere war mir dann doch etwas zu heiß 8o


    An Erfahrung bin ich trotzdem wieder reicher geworden :thumbup:

    Hi alle zusammen,


    hab da mal wieder ein kleines Problem(chen) wo ich eure Hilfe gebrauchen könnte.
    Es geht um eine IRC 5 Steuerung mit einem IRB 1600.


    Das Problem ist schnell beschrieben :|:
    3 Punkte (Unterschiedliche Stellung) in Koordinatensystem A geteacht.

    Um diese 3 Punkte an 3 weitern Stationen zu duplizieren habe ich einfach Koordinatensystem B, C und D eingemessen und fahre nur mit ändern des Werkobjektes diese insgesamt 12 Punkte an.

    Funktioniert soweit auch. Jedoch in Koordinatensystem D kann der Roboter 2 von 3 Punkten nicht anfahren, da er irgendwie anders herum hinter sich her fahren möchte...

    Auch wenn die Vorposition schon 20cm davor ist, dreht er dann einfach ab.

    Es handelt sich um MoveJ Punkte, die angefahren werden, ob er mit MoveL diese direkt anfährt habe ich heute nicht mehr ausprobiert.


    Habt ihr Ideen woran das liegen könnte? Evtl, dass die Teachpunkte und die letzten Punkt knapp um die 180° auseinander liegen und der dann lieber den anderen Weg nehmen möchte???


    Habe zum Verständnis eine kleine Zeichnung angehangen.
    Schon mal danke für eure Hilfe.


    Btw: Sorry für meine Paintskills xD

    Yes, there's a way.
    Don't know how it is called in English but you can find it at the very end of the menue.

    User defined Input and user defined output, i think :/ .

    If you choose one you can open the settings inside to set the name, startbit and length.


    Later in the program you can, for example, read out the user defined Input #1 in a local variable:
    DIN LD001 IGU#(1)


    Hope it will help you :S

    Hi alle zusammen,


    wir versuchen aktuell eine OPC UA Schnittstelle aus RobotStudio mit einer simulierten PLC zu erstellen.

    Damit sollen dann später ein Signalaustausch mit SPS und Rob simuliert werden.


    Wir haben einen UpcUaClient in Robotstudio angelegt und uns auch mit der PLC verbunden.

    Jedoch fehlen in RobotStudio die benötigten Ordnerinhalte von den Inputs, die aber auf SPS Seite angelegt wurden.


    Hat jemand von euch auch das auch schon mal gehabt und eine Lösung gefunden?

    Ich habe mal Screenshots von RobotStudio und der SPS angehangen, damit man nachvollziehen kann von was ich rede.


    Man kann sehen, dass in der SPS definitiv mehr in dem Ordner ist, als RobotStudio anzeigt.

    Also wir hatten das damals (2019) bei Kuka in der Schulung so gemacht:


    DEF Unterprogramm1

    .....

    CONTINUE
       PTP Nachpos1

    END


    DEF Unterprogramm2

    CONTINUE

       PTP Nachpos1

    ....

    END


    Es musste PTP und nicht SPTP benutzt, und soweit ich mich erinner ein Continue über beide geschrieben werden. Ich meine mich auch zu erinnern, dass es GENAU die selben Positionen sind.
    Hatten das damals mit der Homeposition gemacht.
    Ob das immer noch funzt, bzw orginell ist, kann ich nicht sagen.

    Wir haben es gelöst, wie man es machen "könnte".


    Greifer im Koordinatensystem "Welt" auf 0° drehen und mit dem einzumessenden TCP auf eine Spitze fahren. Den 1. Punkt mit tool0 in "welt" teachen.

    Greifer um 180°(Rz) in "Welt" drehen und wieder mit dem TCP auf die Spitze fahren. 2. Punkt mit tool0 in "Welt" teachen.


    Jetzt einfach die Differenz der beiden Punkte in X und Y berechnen und dann durch 2 teilen.
    Zack und schon habe ich meinen Versatz des TCP in X und Y zu meinem tool0.


    Z muss dann aber aus CAD genommen oder, evtl. händisch eingemessen werden.

    Man findet den Befehl in der Informlist unter ->Bewegung ->TCPON ->TCPOFF.

    Ich habe gerade nochmal nachgeguckt. Wir haben uns den Befehl TSYNCRST (Twin Steuerung) über Parameter freigeschaltet. TCPON/OFF war doch schon da.

    Wie gesagt, einmal kurz die Hotline anrufen, die werden dir schnell weiter helfen, falls der bei dir nicht vorhanden ist.


    Gruß
    Maverick

    El Cattivo, tatsächlich =O       :uglyhammer_2:


    Sobald man einmal ein Zeile noch oben oder unten springt, egal wo, verschwindet das wieder. Klickt man ganz stumpf einfach Zeile für Zeile durch, bleibt der TCP ON...
    Gut, das muss man erst mal wissen. MERKE: Keine Pfeiltasten drücken, wenn TCP ON  8o

    Hab natürlich öfter mal ne Zeile nach unten gedrückt, deswegen war das auch so sporadisch, mal da und mal nicht.


    Vielen Dank für eure Antworten, habt mir beide weiter geholfen.
    Werde jetzt einfach mit nem kleinen Unterprogramm den Greiferspezifischen TCP schalten :)

    Hi alle Zusammen,


    ganz kurz und knapp:
    Wir möchten bei einem IRB660 (IRC5) einen TCP am Greifer einmessen.
    Ist mein erster Palettier-Roboter. Hab alle Berechnungen und Tests mit einem TCP aus dem CAD gemacht. Für die Feinjustage sollte dieser aber jetzt ordentlich vermessen werden.
    Das funktioniert aber nicht so einfach, da ich ja nur 4 Achsen habe und nicht wie bei einem 6Achser umorientieren kann.

    Könnt ihr mir sagen, ob es dennoch möglich ist eine Messspitze z.B., ordentlich (Ohne CAD), in einem Palettier-Roboter einzumessen?

    Vielen Dank schon mal.

    Boah, ja Leute mein Fehler :waffen100: .


    Ich meine natürlich die ganze Zeit TCP ON und den benutze ich auch aktuell im Programm -.-.
    Danke El Cattivo.


    Se.bastian, der muss über Parameter freigeschaltet werden, hatten wir damals auch bei der YASKAWA Hotline angefragt.


    Nichts desto trotz gibt es immer noch das gleiche Problem. Sobald ich einen TCP ON schalte hält er nicht so lange, bis ich ihn wieder OFF schalte.
    Das ist ja mein eigentliches Problem. Über Bitcodierung das TOOL abfragen ist kein Problem, nur ständig immer wieder die Anweisung TCP ON vor jeder berechneten Bewegung ist echt nervig.

    Am liebsten würde ich meinen TCP am Anfang des Unterprogramms definieren und dann soll dieser bis Ende des Unterprogramms, wo ich ihn wieder ausschalte, halten...

    Hi Sebastian,

    vielen Dank für deine Antwort. Ist ja eher mau, was Antworten im YASKAWA Bereich angehen^^.

    Hilft mir leider nur bedingt weiter, da ich genau das machen will, wie oben beschrieben.
    Vielleicht habe ich mir nur nicht deutlich genug ausgedrückt. Also hier noch mal eine Detailantwort ;)

    Greifer 1 : 58KG
    X : 6, Y: 0, Z : 200

    Greifer 2 : 75KG
    X : 25, Y: 0, Z : 210

    Greifer 3 : 83KG

    X : 31, Y: 0, Z : 236


    Generell sehen diese 3 Greifer gleich aus, sind nur von der Dimensionierung anders. Ich möchte also einen Theoretisch berechneten Punkt mit Greifer 1, 2 oder 3 anfahren.
    Dazu muss ich eigentlich aber auch das Werkzeug wechseln, da ich auch unterschiedliche Gewichte habe.


    Meiner Meinung nach ist der TOOL ON dafür schon richtig eingesetzt, funktioniert nur nicht, wie ich mir das eigentlich vorstelle...


    Hast du noch eine Idee, wie ich das machen könnte?
    Vielen Dank schon mal für deine Mühe =)

    Hi alle Zusammen,

    habe mal eine Frage bezüglich des TCP ON Befehls in der YRC1000 Steuerung.

    Wir haben mehrere Greifer mit unterschiedlichem TCP's.

    Ich möchte aber gerne im gleichen Programm einfach die Bitcodierung des aktuellen Greifers abfragen und dadurch einen TOOL ON (#XXX) erzeugen.
    Irgendwie übernimmt er einen TCP ON aber nur auf den nächsten Bewegungsbefehl. Sollte der nicht so lange "ON" sein bis ich wieder TCP OFF setze?
    Mein Programm besteht aus lokalen Punkten UND P-Variablen, die nacheinander angefahren werden. Zwischendurch werden auch nochmal Ausgänge gesetzt oder Punkte manipuliert.

    Aktuell würde das dann ca. so aussehen, damit ich alle Punkte mit TOOL ON anfahre:


    TOOL ON (#6)
    MoveJ

    TOOL ON (#6)
    Move J P012

    TOOL ON (#6)
    MoveL

    TOOL OFF


    In meinem Kopf sollte das aber so aussehen ;)

    TOOL ON (#6)

    MoveJ

    MoevJ P012

    MoveL

    TOOL OFF


    Mach ich was falsch? Oder muss man etwas beachten, was den Befehl TOOL ON zurück setzt?


    EDIT:
    Bitte alle TOOL ON durch ein TCP ON ersetzen ;) danke

    Jetzt habe ich doch noch eine Frage.


    Ist es möglich eine definierte Eingangsgruppe als String auszulesen und diese als Jobaufruf zu verwenden?


    Mit "CALL S000" kann man auf jeden Fall, auch wenn es irgendwie unschön aussieht, schon mal einen Job über einen definierten String aufrufen. Den hab ich aber dann händisch eingetragen.
    Aber wie bekomme ich einen String ausgelesen, damit ich den für sowas verwenden kann?

    Hat hier jemand eine Idee? Oder wie handhabt ihr das mit der Jobauswahl?
    Hab nämlich gefühlt eine Million Programme die aufgerufen werden müssen und dafür wäre das über einen String am einfachsten.

    Ach du meine Güte, ich habs gefunden.:uglyhammer_2:

    Sorry Leute, bin mit YASKAWA und dem Umgang einfach noch zu neu...
    Habe mir die letzten Tage einfach die Seele aus dem Leib gesucht und jetzt habe ich es gefunden.


    Ist fast peinlich zu sagen, aber wenn man in dem Menü "BEN.DEF.EING.GRUPPE" ist, kann man oben im Reiter einfach auf "ANZEIGE" -> "EINSTELLUNGEN" gehen und schon hat man alles da:waffen100:.


    Ich muss mich einfach noch an die Menüführung gewöhnen... Vor allem weil bei YASKAWA fehlende Sachen nicht ausgegraut, sondern einfach nicht angezeigt werden, ohne entsprechende Berechtigung oder ohne im richtigen Abschnitt/Fenster zu sein.

    Hi alle zusammen,


    ich bräuchte mal eure Hilfe bezüglich Aus und Eingangsdefinition von einer YRC1000 Twin Steuerung.


    Und zwar müssen wir X,Y und Z Offsets mit der SPS austauschen. Dazu würde ich mir gerne Benutzerdefinierte Ein- und Ausgangsgruppen erstellen.

    Kann mir jemand sagen, wie ich diese definieren kann?


    Unter dem Reiter "EIN/AUS" finde ich zwar "BEN.DEF.EING.GRUPPE" aber wie lege ich da welche an?

    Hier finde ich aufgelistet IGU#(1) bis IGU#(64) kann diese aber nicht definieren.


    Der plan ist nämlich diese von der SPS auszulesen und dann damit weiter zu arbeiten.
    Ganz grob sollte das so aussehen:

    Code
    'Auslesen von SPS
    DIN D000 IGU#(1) 
    
    'Später der Jobaufruf mit OFFSET
    CALL JOB:OFFSET (D000)
    
    'Im JOB OFFSET:
    GETARG LD001 IARG#(1)

    Hat hier jemand eine Idee, wo und wie ich das am besten mache?

    Hi alle zusammen,


    es ist das erste mal, dass wir einen KUKA mit UL Zertifizierung für Amerika bei uns aufbauen.
    Als ich mich darüber informiert habe, wurde mir von KUKA damals mitgegeben, dass man bei der IBN die Spannungsversorgung in WoV auf 400V einstellen muss.

    Bei einem UL Zertifizierten Roboter ist die nämlich auf 480V eingestellt.


    Kann mir jemand sagen, wie man das am besten macht? Ich muss den ja erst mal bei uns ans Netz anschließen um ihn zu starten.

    Muss man da noch etwas beachten?


    Könnt gerne mal eure Erfahrungen teilen und evtl. auch zeigen, wo man das einstellen kann.

    Vielen Dank schon mal.