Beiträge von Drudge

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 glaube um RSI kommst du nicht rum ...

Ausser du fährst ganz langsam und es ist egal wenn der Roboter träge reagiert ... dann könnte mann einen versuchen mit $ADVANCE = 1 und TOOL_CORR zu arbeiten. Aber Bewegungen im Interrupt werden immer rucklig sein...

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:

GLOBAL DEF irMIG_ServicePos ()
  DECL E6POS pTemp, pRet


  INTERRUPT OFF iIntr_MIG_ServicePos

  IF ($PRO_ACT AND $ROB_STOPPED AND $WORKSTATE1) THEN
    BRAKE
    WAIT FOR $ROB_STOPPED
    ;in Servieposition fahren
    pRet = $POS_ACT

    SWITCH $ACT_BASE
     CASE 0, 1
      ;aus Korb hochfahren
      WHILE ($POS_ACT.Z<0.0)
        PTP_REL {Z 5.0}
      ENDWHILE
      ;in Home2 VorPos fahren
      pTemp = $POS_ACT
      IF $POS_ACT.Z<250.0 THEN
        pTemp.Z = 250.0
      ENDIF
      IF $POS_ACT.X>2340.0 THEN
        pTemp.X = 2340.0
      ENDIF
      PTP pTemp
      ;in finale Serviceposition fahren
      $AXIS_HOME[2] = XHOME2
      PTP XHOME2

     CASE 2, 3, 4
      ;aus Korb hochfahren
      WHILE ($POS_ACT.Z<100.0)
        PTP_REL {Z 5.0}
      ENDWHILE
      ;in Home2 VorPos fahren
      pTemp = $POS_ACT
      IF $POS_ACT.Z<350.0 THEN
        pTemp.Z = 350.0
      ENDIF
      IF $POS_ACT.X>1200.0 THEN
        pTemp.X = 1200.0
      ENDIF
      PTP pTemp
      ;in finale Serviceposition fahren
      $AXIS_HOME[2] = XHOME2
      PTP XHOME2

     DEFAULT
      INTERRUPT ON iIntr_MIG_ServicePos
      RETURN

    ENDSWITCH

    ;Fehler beheben
    WAIT FOR ((NOT diMIG_ServicePos) OR $CYCFLAG[iCF_PLC_Cancel]) ;Warte darauf dass Taster geloest ist
    REPEAT  ;warte auf erneutes Druecken des Tasters
      WAIT FOR (diMIG_ServicePos OR $CYCFLAG[iCF_PLC_Cancel])
      IF NOT $CYCFLAG[iCF_PLC_Cancel] THEN
        WAIT SEC 0.2
      ENDIF
    UNTIL (diMIG_ServicePos OR $CYCFLAG[iCF_PLC_Cancel])

    ;zurueck auf Fehlerposition
    SWITCH $ACT_BASE
     CASE 0, 1
      ;in Home2 VorPos zurueck fahren
      pTemp = pRet
      IF pTemp.Z<250.0 THEN
        pTemp.Z = 250.0
      ENDIF
      IF pTemp.X>2340.0 THEN
        pTemp.X = 2340.0
      ENDIF
      PTP pTemp
      ;zur Position ueber der Naht fahren
      pTemp = pRet
      IF pTemp.Z<0.0 THEN
        pTemp.Z = 0.0
      ENDIF
      PTP pTemp
      ;zur Fehlerposition zurueck fahren
      WHILE ($POS_ACT.Z>(pRet.Z+5.0))
        PTP_REL {Z -5.0}
      ENDWHILE
      PTP $POS_RET

     CASE 2, 3, 4
      ;in Home2 VorPos zurueck fahren
      pTemp = pRet
      IF pTemp.Z<350.0 THEN
        pTemp.Z = 350.0
      ENDIF
      IF pTemp.X>1200.0 THEN
        pTemp.X = 1200.0
      ENDIF
      PTP pTemp
      ;zur Position ueber der Naht fahren
      pTemp = pRet
      IF pTemp.Z<100.0 THEN
        pTemp.Z = 100.0
      ENDIF
      PTP pTemp
      ;zur Fehlerposition zurueck fahren
      WHILE ($POS_ACT.Z>(pRet.Z+5.0))
        PTP_REL {Z -5.0}
      ENDWHILE
      PTP $POS_RET

    ENDSWITCH
  ENDIF

  INTERRUPT ON iIntr_MIG_ServicePos
END

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:

;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:

GLOBAL DEF irMIG_ServicePos ()
  DECL E6POS pTemp, pRet
  DECL FRAME fTemp
  DECL REAL rVel




  INTERRUPT OFF iIntr_MIG_ServicePos

  IF ($PRO_ACT AND $ROB_STOPPED AND $WORKSTATE1) THEN
    BRAKE
    WAIT FOR $ROB_STOPPED
    ;in Servieposition fahren
    rVel = $VEL.CP
    $VEL.CP = 0.3  ;m/s
    pRet = $POS_ACT
    pTemp = pRet
    SWITCH $ACT_BASE
     CASE 0, 1
      IF pTemp.Z<0.0 THEN
        pTemp.Z = 0.0
        LIN pTemp
      ENDIF
      IF pTemp.Z<250.0 THEN
        pTemp.Z = 250.0
      ENDIF
      IF pTemp.X<2340.0 THEN
        pTemp.X = 2340.0
      ENDIF
      LIN pTemp
      ;in finale Serviceposition fahren
      $AXIS_HOME[2] = XHOME2
      PTP XHOME2

     CASE 2, 3, 4
      IF pTemp.Z<100.0 THEN
        pTemp.Z = 100.0
        LIN pTemp
      ENDIF
      IF pTemp.Z<350.0 THEN
        pTemp.Z = 350.0
      ENDIF
      IF pTemp.X>1200.0 THEN
        pTemp.X = 1200.0
      ENDIF
      LIN pTemp
      ;in finale Serviceposition fahren
      $AXIS_HOME[2] = XHOME2
      PTP XHOME2

     DEFAULT
      INTERRUPT ON iIntr_MIG_ServicePos
      $VEL.CP = rVel
      RETURN

    ENDSWITCH

    ;Fehler beheben
    WAIT FOR ((NOT diMIG_ServicePos) OR $CYCFLAG[iCF_PLC_Cancel]) ;Warte darauf dass Taster geloest ist
    REPEAT  ;warte auf erneutes Druecken des Tasters
      WAIT FOR (diMIG_ServicePos OR $CYCFLAG[iCF_PLC_Cancel])
      IF NOT $CYCFLAG[iCF_PLC_Cancel] THEN
        WAIT SEC 0.2
      ENDIF
    UNTIL (diMIG_ServicePos OR $CYCFLAG[iCF_PLC_Cancel])

    ;zurueck auf Fehlerposition
    pTemp = pRet
    SWITCH $ACT_BASE
     CASE 0, 1
      IF ((pTemp.Z<250.0)OR(pTemp.X>2340.0)) THEN
        IF pTemp.Z<250.0 THEN
          pTemp.Z = 250.0
        ENDIF
        IF pTemp.X>2340.0 THEN
          pTemp.X = 2340.0
        ENDIF
        LIN pTemp
        pTemp = pRet
      ENDIF
      IF pTemp.Z<0.0 THEN
        pTemp.Z = 0.0
        LIN pTemp
      ENDIF
      LIN $POS_RET

     CASE 2, 3, 4
      IF ((pTemp.Z<350.0)OR(pTemp.X>1200.0)) THEN
        IF pTemp.Z<350.0 THEN
          pTemp.Z = 350.0
        ENDIF
        IF pTemp.X>1200.0 THEN
          pTemp.X = 1200.0
        ENDIF
        LIN pTemp
        pTemp = pRet
      ENDIF
      IF pTemp.Z<100.0 THEN
        pTemp.Z = 100.0
        LIN pTemp
      ENDIF
      LIN $POS_RET

    ENDSWITCH
    $VEL.CP = rVel
  ENDIF

  INTERRUPT ON iIntr_MIG_ServicePos
END

Verwendete Softwareversionen:

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 )

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?

Gruss Drudge

hab grad nicht die Zeit, aber schau mal im BAS.src ... gab es da nicht mal eine globale Variable mit der die Programmierte Geschwindigkeit multipliziert wird?
Falls nicht, halt selber die BAS.src mit einem Faktor ergänzen, über den du die Geschwindigkeit regeln kannst.
(Achtung nicht Update resistent)

greez Drudge

btw. ein einfaches '=' ist eine Zuweisung und kein Vergleich

welche Störungsmeldung kommt den genau? Ist es die standart Arbeitsraumüberwachung oder eventuell bereits eine Safe-Operation Form?

Könnte eventuell auch die Fahrfreigabe von der SPS sein ...
Mach doch schnell ein Archiv des Roboters ... dann schau ich in die Konfiguration. Sollte kein Problem sein, heraus zu finden was der $IN[55] alles so macht.

Hallo Froschkönig,

dein Problem ist, dass du für den Programmstart bei KUKA
1. entweder einen der grünen Startknöpfe auf dem KCP drücken musst
2. oder über ein digitales Eingangssignal einen Signalwechsel von low auf high generieren musst

Zweitens könntest du über den Submit realisieren indem du ein digitales Ausgangsignal physikalisch auf einen digitalen Eingang brückst ...

greez Drudge

Hallo Tom,

• Es gibt die Langtexte (reiner Beschreibungstext in der IO-Liste auf dem KCP),
  die können in eine Textdatei exportiert werden und auch wieder importiert werden.


• Weiter gibt es die Signaldefinitionen (für Signalnamen im Programmcode),
  die kannst du offline in die Datei KRC\R1\Systen\$config.dat in die Sektion USER GLOBALS einfügen.

SIGNAL meinSignal $IN[x]
SIGNAL meinSignal2 $OUT[y]

gruss Drudge

Hallo Tom,
was verstehst du genau unter dem Begriff "Symbolik"?
gruss Drudge

Hallo domi,

das Problem ist halt, dass durch das Betreten der Zelle die Sicherheiten unterbrochen und dadurch die Roboterantriebe ausgeschaltet werden. Darum braucht es nachher einen Programmstart (grüne Taste).

Die einfachste Lösung wäre wohl:
1. Teilekontrolle
2. Falls nicht i.O. entsprechende Statusmeldung absetzen
3. WHILE "Teilekontrolle nicht i.O."
HALT (Programmstop)
ENDWHILE
4. Statusmeldung wieder löschen

Dadurch startet und quittiert der Bediener halt mit der grünen Starttaste.

greez Drudge

hmm das heisst in dem Moment sind die Antriebe bereits ein und die Sicherheiten quittiert?
Wieso ist dann das Programm gestoppt?
Respektive wie liest du die Softkeys ein, über User-Tech, Submit oder was?

Die Lösung mit am wenigsten Widerstand von KUKA ist, dass du im Automatik extern arbeitest und am DeviceNet einen Wagokoppler packst, wo du gewisse Ausgänge auf gewisse Eingänge brückst... das ganze Starten und Stoppen ginge dann über den Submit.
Es gibt auch noch eine von KUKA nicht erlaubte Möglichkeit mit EA Softlinking ...

ich bin nicht sicher ob ich wirklich verstanden habe, was du willst. So wie ich dich verstehe, würde ich sagen "eher nicht".
Schon beim chinesischen Orangenkonzern nachgefragt?