Posts by Drudge

    Ja gehen wir mal davon aus, deine Zielposition ist eine Globale Pos. Und zwar die PX071. Dann würde das wiefolgt aussehen (vermute ich):

    Wie gesagt, das Zeroing kann (sofern der Robotertyp es erlaubt) relativ einfach nachgerüstet werden.

    Das nächste wäre vermutlich die HOME2. In der Praxis ist es meist so, dass keine extreme Genauigkeit nötig ist. Und wenn dann nur in wenigen Positionen, die Notfalls nachgeteacht werden können. Dann reicht es einfach zwei Spitzen oder Ecken (eine am Werkzeug eine fix in der Zelle) exakt aufeinander zu teachen.
    Wenn dann mal eine Justieren nötig wird, ist es meist nur an einer Achse nach einer Reparatur oder so (sofern die Wartungsintervalle für die Batterien eingehalten wurden). Da kann auf die Markierungen gefahren werden und mal so das Achsen-Null definiert werden. Durch die HOME2 kann jetzt geprüft werden, ob der Justage korrekt ist. Falls nicht kann der Pulse-Offsetwert der Nullposition an der neu justierten Achse erhöht oder reduziert werden, bis die HOME2 Position wieder einigermassen stimmt.

    Nein er würde nicht zum Punkt 1 springen, weil nach dem Entnehmen die MaschineLeer ist und nicht mehr Fertig. (Der Code ist mehr ein Prinzipbeispiel und es ist gut möglich dass er Fehler enthält.)

    Statt den Schrittnahmen zu speichern, könntest du auch eine Ixxx Variable nehmen und Schrittnummern speichern. Und dann würde ich statt Jump-Befehle den SWITCH-CASE Verteiler verwenden.

    Für das Freifahren definiere ich jeweils Zonen und bewege je nach Zone in einen sicheren Bereich und von da dann direkt in die Grundstellung. Oder wenn in einer Sperrzone, dann das automatisch Freifahren verweigern,
    Aber dein Ansatz sollte sicher auch gut funktionieren.

    Die Frage ist: Möchtest du im Fehlerfall einfach die Roboter justieren wie mit dem EMD oder brauchst du höhere Präzision?

    Ich hätte den Zeroing-Sensor präferiert, wieso geht der nicht bei euch?

    Zeroing-Sensor mit europäischem Messtaster ist das was dem EMD am nächsten kommt. Funktioniert aber nicht für alle Robotermodelle und der Roboter muss explizit mit der Zeroing Option bestellt werden. (Kann allerdings auch relativ einfach nachgerüstet werden.)

    "irgendeine Prüfposition" ist wohl die HOME2 Position. Dafür baust du dir zwei Messspitzen (eine am Roboterflansch und eine fix in der Zelle) inklusive Hülse. Dann teachst du die HOME2 Position so, dass die Spitzen aufeinander sind und die Hülse schön über beide Spitzen bewegt werden kann.
    Im Problemfall kannst du dann den Roboter ungefähr justieren und wieder in diese exakte Position bringen. Dann solange an den Offsetwerten spielen bis die Position wieder passt.
    So kannst du ohne Zeroing-Sensor die Justage so wieder herstellen, dass nichts nachgeteacht oder korrigiert werden muss.

    Das MotoCalv funktioniert, wenn sonst nichts geht ausser komplett neuvermessen mit Spezialausrüstung. Oder wenn eben die Werksmässige Kalibrierung für die Anwendung noch optimiert werden soll. Allerdings wird eine nachträgliche Kalibrierung mit MotoCalv nicht 100% mit der Werkskalibrierung mit der die Programme erstellt wurden übereinstimmen...

    Für gewisse Robotermodelle gibt es Kalibrierplatten mit denen der Roboter in die exakte mechanische Nullstellung gebracht werden kann. Und so die Offsetwerte neu bestimmt werden.


    In den meisten Fällen können aber verlorene Kalibrierwerte einfach und schnell über das HOME-Menü wieder hergestellt werden. (Ausser Motor und / oder Getriebe wurden mechanisch abmontiert) Dazu einfach folgendes beachten:
    1. regelmässig die Encoderbatterien im der Steuerung und im Roboterarm ersetzen.
    2. Im Fehlerfall nicht rumdrücken, sondern einen Experten um Hilfe bitten ;)

    Ich würde das vermutlich über eine Art State-Machine versuchen. Damit meine ich eine Schrittkette, die nicht über Schrittzahlen sondern über Signalzustandskombinationen funktioniert.


    Kommt drauf an was für eine Zone es ist und wer den Roboter stoppen soll. Das müsste aber der ursprüngliche Inbetriebnehmer wissen und gegebenenfalls auch dokumentiert haben.

    Ich würde nicht an der Safetykonfiguration oder Verdrahtung ohne genaustes Wissen über das Konzept und die Hintergründe rum fummeln. Such dir bitte jemand, der die Robotersteuerung, das SaveMove und das Sicherheitskonzept der Anlage gut kennt. ;)

    Hallo Martl,

    ja diesen Ansatz hatte ich auch schon überlegt. Aber weil ich ja die Positionen überschleifen will, gibt es keine Vorlaufstops und die Bahnplanung wird im Vorlauf gemacht. Dadurch kommt es oft vor, dass eben schon der überschliffene Endpunkt eingelesen wurde und erst dann das Signal für Zyklusstop kommt.

    Bei PTP auf LIN zuerst eine PTP in Richtung wie LIN, funktioniert wirklich ohne einen Genauhalt? (PTP und LIN nicht SPTP und SLIN) ... müsste ich bei Gelegenheit mal testen.

    gruss Drudge

    fubini bis jetzt ist meine empfunde Erfahrung auch, dass SPTP hackeliger und z.T. auch langsamer als PTP ist.

    Bei den PTP Bewegungen konnte ich % für die Achsbewegungen eine Überschleiftoleranz programmieren und nicht den TCP einschränken. Geht das mit SPTP auch oder wird SPTP völlig anders berechnet und ausgeführt? Ich habe einfach das Gefühl, dass SPTP keine Achsbewegung mehr ist sondern eine Bahnbewegung mit Achsrücksichtsnahme. Du weisst da sicher mehr, oder?

    Hallo Ihr KUKA Bändiger,

    ich hatte exakt gleiche Problem wie Martl, dass der Robi beim Anfang des Überschleifbogens bereits anhält, wenn bis dann der Vorlauf nicht schon genug weit ist.

    Das ist ziemlich ungünstig, wenn man den seltenen Fall hat, dass der Roboter in einer Zelle verschieden Stationen bedienen muss, die jeweils über Signale freigegeben werden. Und auch noch schnelle Fahrbewegungen gemacht werden sollen und für SPTP grosse Überschleifradien definiert werden... dann stockt die Roboterbewegung regelmässig.

    Leider war es bei dieser Anlage (Softwarestand?) so, dass der Roboter immer einen Genauhalt machte bei PTP-LIN (oder war es LIN-PTP?), deshalb war ich gezwungen alles auf SLIN und SPTP umzubauen. Jetzt habe ich keine Genauhalte mehr, dafür Ruckler und spastische Bewegungen. ;)

    Nun das von euch bereits beschriebene Verhalten, verursacht mir aber noch ein anderes Problem. Falls die SPS einen "Stop bei Zyklusende" auslöst, dann wird die letzte "Stations-Home" Bewegung nicht fertig ausgeführt, sondern der Roboter bleibt beim Anfang des Überschleifbogens stehen. Weil ja die Überschleifbewegung (noch) nicht abgeschlossen werden kann. In meinem Freifahr/Grundstellungsfahr-Programm werte ich zuerst $POS_ACT aus um, fest zustellen wo ich gerade bin und welchen Weg ich nehmen muss. Hier liegt das Problem! In $POS_ACT steht die Position vom Anfang des Überschleifbogens. Ich bräuchte hier aber die (überschliffene) Zielposition. Denn wenn ich jetzt SPTP $POS_ACT mache, bewegt sich der Roboter zuerst zu dieser Zielposition und dann wieder zurück zum Anfang des Überschleifbogens. Ich habe $POS_RET, $POS_INT und $POS_FOR angeschaut, aber die bieten mir keine Lösung.

    Weiss jemand einen Befehl um den Angefangenen Fahrbefehl abzubrechen und zum Zielpunkt zu fahren? Oder eine Variable in der ich den zu überschleifenden Zielpunkt finde?

    gruss Drudge

    ich bin zwar nicht auf dem neusten Stand und ich weiss nicht genau was für einen Roboter und Steuerung du verwendest. So wie ich deinen Text interpretiere hast du einen normalen Quantec mit einer stink normalen KRC4 ... oder?

    Ich vermute stark, dass du nicht um eine Kraftmessdose und der entsprechenden KUKA Softwareoption (um in "Echtzeit" die Bahnplanung zu modifizieren) herum kommst...

    gruss Drudge

    Habe plötzlich realisiert, dass ja vom ArcTechBasic nur die CP Geschwindigkeit reduziert wird. Darum als einfache Lösung die Freifahr-Interruptroutine mit PTP Bewegungen bestückt:

    saletti Stef,

    ja bin wiedermal ein bisschen einen Robi vergewaltigen ;).
    Danke dein verlinkter Post hatte ich vorher nicht gefunden. Der beantwortet meine Frage: in einer Interruptroutine können die Bewegungsparameter nicht geladen werden.

    Das ArcTech Advance ist hier keine Option ... da muss ich versuchen anders zu schweissen, damit die Geschwindigkeit im Fehlerfall höher ist.

    grüsse ins AG ;)
    Drudge

    Hallo zusammen,

    ich stehe im Moment an. Und zwar habe ich eine KUKA Schweissapplikation mit ArcTechBasic. Bei Zünd- oder Schweissfehler soll der Bediener zuerst schauen ob der Draht freigebrannt ist und falls ja, einen Taster drücken, damit der Roboter mit dem Schweissbrenner in eine Serviceposition fährt. Sobald der Brenner gereinigt wurde, soll wieder der Taster gedrückt werden und der Roboter fährt im Programm fort.
    Ich habe das ganze mit einem Interrupt gelöst. Es funktioniert auch 95% der Zeit. Nur manchmal fährt der Roboter mit Schweissgeschwindigkeit (1mm/s) in die Serviceposition ... obwohl ich im Interruptprogramm eigentlich 0.3 m/s programiert habe. Was mache ich falsch?

    Interrupt Deklaration:

    Code
    ;Roboter in Serviceposition bei Schweissfehler fahren
        $CYCFLAG[iCF_MIG_ServicePos] = diMIG_ServicePos AND $PRO_ACT AND $ROB_STOPPED AND $WORKSTATE1
        GLOBAL INTERRUPT DECL iIntr_MIG_ServicePos WHEN $CYCFLAG[iCF_MIG_ServicePos]==TRUE DO irMIG_ServicePos ()
        INTERRUPT OFF iIntr_MIG_ServicePos ;nur waehrend dem Schweissen aktivieren

    Interrupt Routine:

    Verwendete Softwareversionen:

    Code
    KSS Version=V8.3.39
    ArcTechBasic=1.5.7
    BoardPackage=1.4.0
    DiagnoseSafety=2.1.0
    GripperSpotTech=4.0.7
    Profinet ProfiSafe Device=3.2.2
    SafeOperation=3.2.4
    UserTech=3.3.5

    greez Drudge

    d4nuu8 ja haste recht. Es ist eine Software Option die LP beinahe 500 € kostet ... hahaha 500€ um eine bestehende Ethernetschnittstelle im Windows zu aktivieren :ylsuper:

    ich glaube da kaufe ich lieber einen kleinen Managed-Switch und 2 Meter Netzwerkkabel. Und erweitere das KLI um ein weiteres Virtuelles Netzwerk (mehr ist das KONI nämlich auch nicht :lol:)

    Hallo zusammen,

    immer wieder stolpere ich über die EtherNet Schnittstelle KONI am Steuer-PC der KRC4. Soweit ich verstanden habe ist diese Schnittstelle für Optionen gedacht. Jedoch habe ich beim jetztigen Roboter folgende Belegung:


      • am KLI ist direkt der X66 (ProfiNet) angeschlossen

      • am X44 (EtherCat) ist die SPS angehängt. (Die SPS ist der DHCP Server)

      • am EtherNet Switch ist die SPS (DHCP), das HMI-Panel und mein Programmier-PC angeschlossen.

      • der Service-Port auf der CCU ist selber DHCP.


    Die Konfigdateien vom KLI und KONI scheinen sehr ähnlich zu sein, darum habe ich mir überlegt den KRC4 PC über das freie KONI direkt an den EtherNet Switch anzuschliessen. So dass ich mit dem Programmier-PC das HMi, die SPS und den Roboter ohne Umhängen programmieren könnte.
    Darum meine Fragen:
    [list type=decimal]

    • Was ist nun das KONI genau (im Detail)? Weil in den KUKA Doku's kann ich nichts brauchbares finden, ausser der Aufschlüsselung des Kürzels KONI.

    • Ist es überhaupt möglich mit dem WorkVisual über das KONI auf die Robotersteuerung zu zugreifen?

    • Falls ja, wie müsste ich die Steuerung konfigurieren, damit das geht und der KPC seine IP über den DHCP bezieht?

    • Sind diese KONI Konfigurationen Update sicher?

    [/list]

    Gruss Drudge