Posts by fubini

    🙈 Jetzt hab auch ich's kapiert. Deine zwei Roboter sind unterschiedlichen Typs und wenn's blöd läuft auch noch unterschiedlich in der Versionsnummer. Das kam aus deiner Beschreibung nicht so deutlich raus und kann dann über WoV Projekt so nicht klappen. Genau einer der Gründe warum man die beteiligten Anlagen mit Typ und Version immer mit angeben sollte. Normalerweise macht man so was auch nur bei Zwillingsanlagen, d.h bei Anlagen die identisch sind. Du willst also nicht duplizieren sondern nur Teile der Konfiguration von einer Anlage auf andere kopieren. Dann musst du wie Hermann schon gesagt hat entweder den Projektmerge in WoV hernehmen oder eben zu Fuß. Ich persönliche habe jetzt mit dem Merge keine so schlechten Erfahrungen zumindest mit neueren WoV Versionen.


    Fubini

    Sollte aber gehen. Wie hast du es genau gemacht? Robtrafomeldung dürfte eigentlich nur kommen , falls der Robotertyp der auf der RDC gespeichert ist nicht dem Robotertyp für den die Maschinendaten im WoV Projekt sind übereinstimmt.


    Liefert $Robtrafo (Wert auf der RDC) was anderes als $Trafoname (Wert in den Maschinendaten)? Wenn ja wer hat recht? Ich vermute mal einer der beiden Roboter hat falsche Maschinendaten.


    Fubini

    Ich glaub auf die Steuerung wird es beim Setup nicht kopiert. Auf dem Installationsmedium ist es auf alle Fälle drauf.


    Fubini

    Man sieht an den Bildern dass es sich auch um eine HA Maschine handeln könnte. Ist das so? Versatz in Größenordnung 3-5 mm könnte da auch von der Absolutgenauigkeit kommen. Ist die Absolutgenauigkeit an? Sind die Lastdaten im Fehlerfall noch wie sie sein sollen?


    Fubini

    Was meinst du mit Projekt? Work visual Projekt einer V8.3 kannst du natürlich nicht auf eine V8.6 deployen. das war nicht was ich meine.


    Was gehen sollte in der VM eine der KRC Versionen zu installieren. Also eine Neuinstallation von der KRC Installations CD.


    Fubini

    Ich vermute stark da brauchst du eine andere OfficeLite VM. V8.6 basiert auf einer KRC4 und V8.7 auf einer KRC5. Damit sind im OfficeLite auch ganz andere Hardwareabstraktionen verbaut. Man kann ebensowenig eine V8.7 auf einer realen KRC4 installieren wie eine V8.6 auf einer realen KRC5.


    Was sehr wohl gehen dürfte ist innerhalb der OfficeLite VM einer KRC4 alle Versionen zwischen V8.3-V8.6 zu installieren, da sie auf der gleichen Steuerungsgeneration basieren.


    Es ist allerdings so, dass seitens KUKA zwischen V8.6 und V8.7 funktionell nichts unterschieden werden soll. D.h. die beiden Softwareversionen sind sozusagen Zwillinge, die nur für verschiedenen Hardwaregenerationen angepasst wurden, d.h. z.B. die Implementierung des PTP in V8.6 ist genau die gleiche wie der PTP mit V8.7. Somit wären die mit der V8.7 erzielten Ergebnisse und Programme wahrscheinlich auch direkt auf einer V8.6 verwendbar (vorausgesetzt die eventuelll installierten Technologiepakete sind identisch).


    Fubini

    Wenn du nur CP-Bewegungen hast kannst du auch mehr kommandieren. Die 180 Grad sind eher die Grenze bei PTP falls du immer in der gleichen Richtung eine Achse drehen willst z.B: weil du den Roboter als Bohrer missbrauchst,. Stell dir vor du stehts bei Null und kommandierst PTP {A1 180}. Soll dann die Achse links oder rechtsrum drehen? Bei Winkeln unter 180 Grad ist das eindeutig.


    Einfach am besten mal selbst mit einfachen Programmen testen und schauen was passiert.

    Alternativ : soweit ich weiß ist in den neuseten Softwareversionen das Feature am Base ausrichten implementiert worden. Wie es genau funktioniert hab ich aber noch nicht gesehen. Müsste man mal KUKA fragen.


    Fubini

    Na klar:


    ;A6 fährt auf 10 Grad

    PTP {A1 0.0, A2 3.0, A3 59, A4 23, A5 34, A6 10)


    ;A6 bleibt auf 10 Grad stehen und bewegt sich nicht

    PTP {A1 -20, A2 -45, A3 11, A4 123, A5 22, A6 10)


    oder


    ;Alle Achsen fahren um den vorgegeben Wert nur A6 steht

    PTP_REL {A1 -20, A2 -45, A3 11, A4 123, A5 22}


    Bei LIN/CIRC wüste ich nicht wie das gehen soll ausser unter bestimmten Randbedingungen

    - Stoßrichtung x des Werkzeugs muss der z-Achse des Flanschsystems entsprechen

    - Drehen um die Stoßrichtung entspricht dann genau dem C Winkel. Schließlich haben wir ZYX-Eulerwinkel ABC und der Roboter macht seine Orientierungsführung über Drehen und Schwenken um die Werkzeugstoßrichtung x


    Fubini

    Quote

    Schreibe ich das so, sagt die Steuerung: Name nicht als Untergramm vereinbart

    Seltsam er kennt ja BAS auch und das ist genau gleich im bas.src definiert. Was hast du den für eine Softwareversion? Recht Alt? Ganz Ganz früher musste man Unterprogramme explizit über EXT deklarieren. Das ist solang her, dass ich da aber die Details auswendig nicht zusammenbringe,


    Quote

    Mein Roboter Experte hat mir das dann so vorgeschlagen, dabei fährt der Robbi den ersten PTP richtig an und fährt dann weit weg vom Tisch in den Achs Endschalter?

    Wundert mich nicht. Liegt dann wohl wie oben schon besprochen an den falschen Posen. Die können so nicht richtig sein. Wenn der Roboter bezogen auf das bewegte Base steht heißt das das er relativ zum sich mit der Tischbewegung wegdrehenden Base konstante Position hat. Um den Roboter dann in der Welt stehen zulassen muss er genau die Bewegung des Tisches ausgleichen.

    Stell dir wieder den Zug vor. Wenn du auf der Erde stehen willst musst du gegen die Zugbewegung anlaufen um nicht mitgerissen zu werden.


    Fubini

    Stell es dir mal so vor. Du bist der Roboter und sitzt im Zug auf deinem Sitzplatz und willst ins Bordrestaurant. Was ich machen will ist du teached den Weg, der dich ins Restaurant bringst und läufst dann den mit vel.cp ab. Das kannst du komplett machen ohne zu Wissen wie der Zug gerade fährt oder ob er sogar steht. Was du machen willst ist sitzen bleiben und den Zug unter dir so zu verschieben, dass das Bordrestaurant unter deinen Hintern kommt. Was ist leichter?


    Das was du machen willst geht aber tatsächlich auch. Dazu solltest du dir $IPO_MODE anschauen. Das dreht letzten Endes die Bedeutung von Tool und Base um und invertiert den pos_act. Wird normalerweise verwendet wenn der Roboter das Werkstück hält und das Werkzeug fest irgendwo installiert ist. Dann kannst für den Roboter einen circ entgegen der Drehrichtung der Zusatzachse programmieren und der Roboter bleibt stehen.

    Also hilft mir der Lösungsansatz von Fubini mit Ex_Base nicht weiter?

    Doch. Er meinte glaube ich nur dass deine Posen dann sicher nicht korrekt sind um deinen Prozess zu realisieren. Wenn deine Posen unbedingt aus Sprutcam kommen müssen muss diese Software das einfach auch unter Berücksichtigung der Tischdrehung richtig generieren. Ob es das überhaupt kann ist kein Problem der Robotersteuerung. Du sagst ja selbst dass es wie gewünscht funktioniert wenn du direkt am Roboter teached. Schau dir da doch mal die Koordinaten an und du wirst feststellen, dass sie nicht konstant sind wie in dem Sprutcam generierten Code. Den Ex_base braucht es auf alle Fälle weil sonst Tisch und Roboter nie als gekoppelte Einheit behandelt werden.


    Fubini