Beiträge von Maximus

Ach wie herrlich ist doch so ein Perspektivwechsel... wenn man mal den Code kopiert und in einer anderen Darstellung sieht, fällt gleich was auf. Ich habe hier schön die Kommentarzeilen mit CONTINUE versehen...

CONTINUE
;Bereich 1 frei

Hier wird zwar nicht auf Ein-/Ausgänge geschaut, aber wer weiß...

DEFFCT REAL Min(Z1:IN, Z2:IN)
REAL Z1, Z2
IF Z1<Z2 THEN
RETURN Z1
ENDIF
RETURN Z2
ENDFCT

Sicher bin ich mir nie...

Hier noch der Loop und die Holen-Funktion.

  LOOP   
    CONTINUE
    doAutomatik=TRUE
    CONTINUE
    doAnf_Band_Out=FALSE
    CONTINUE
    WAIT FOR diAnf_Automatik or diAnf_Wartung or diAnf_Home
    
    CONTINUE
    IF diAnf_Wartung AND NOT doWartung THEN
      ;Wartung -> in Wartungsposition fahren
      wartung()
    ENDIF
    
    CONTINUE
    IF diAnf_Home THEN
      ;HOME -> in Home fahren
      home()
    ENDIF
    
    CONTINUE
    IF diAnf_Automatik AND NOT diAnf_Home AND NOT diAnf_Wartung THEN
      CONTINUE
      doAutomatik = TRUE
      CONTINUE
      IF diTeilekontrolle THEN
        Ablegen ()
      ELSE
        Holen()
      ENDIF
    ELSE
      doAutomatik=FALSE
    ENDIF
    
  ENDLOOP

DEF Holen ( )
  CONTINUE
  IF diANF_AUTOMATIK THEN
    INTERRUPT ON 4 ;Warten unterbrechen, falls Automatikende
  ENDIF
  CONTINUE
  IF NOT $EXT THEN
    home()
  ENDIF
  
  CONTINUE
  WHILE NOT (bBehaelter1 OR bBehaelter2)
    [...gekürzt, hier wird nur getestet welche Bedingung fehlt und Meldungen angezeigt]
  ENDWHILE
  
  INTERRUPT OFF 4
  
  CONTINUE
  IF (diANF_AUTOMATIK or $T1) AND NOT diANF_HOME THEN
    $TIMER[2]=0
    $TIMER_STOP[2]=FALSE
    
    CONTINUE
    IF (bBehaelter1 AND NOT doLEER_BEH1) THEN
      CONTINUE
      ;Bereich 1 frei
      IF MIN(Stapelhoehe[1,1],Stapelhoehe[1,3])>MIN(Stapelhoehe[1,2],Stapelhoehe[1,4]) THEN
        Holen_B1S1()
      ELSE          
        Holen_B1S2()
      ENDIF
    ELSE
      CONTINUE
      IF (bBehaelter2 AND NOT doLEER_BEH2) THEN
        CONTINUE
        ;Bereich 2 frei             
        IF MIN(Stapelhoehe[2,1],Stapelhoehe[2,3])>MIN(Stapelhoehe[2,2],Stapelhoehe[2,4]) THEN
          Holen_B2S1()
        ELSE
          Holen_B2S2()
        ENDIF
      ELSE
        ;kein Bereich frei, nichts tun
      ENDIF        
    ENDIF
    $TIMER_STOP[2]=TRUE
  ENDIF
  
END

Ich habe alles was irgendwie nach I/O aussieht mit CONTINUE versehen. Auch die Ablegen()-Funktion sollte sauber sein, die wird auch in der Holen_B1S1() gerufen und läuft ohne Stopp durch.

Wäre eine Idee.

Dann müsste ich nur den Punkt P1 (über dem Stapel) wieder finden, zum rausfahren. Aber den kann ich in einem globalen Punkt zwischenspeichern. Ich hab nämlich vier Stapel (entsprechend viermal "P1"), aber es gibt ein übergeordnetes Programm, wo das gut reinpassen könnte.

Danke.

Ein KR6 (KR C2 V5.2.15) holt Bauteile von einem Stapel. Er fährt von oben langsam heran und wenn der Sensor das Teil erkennt (Interrupt), wird angehalten (BRAKE), angesaugt und (RESUME) wieder nach oben gefahren. Funktioniert wunderbar, denkt der Roboterprogrammierer und klopft sich auf die Schulter. Der Kunde fragt den Roboterprogrammierer, warum der Roboter "ständig" anhält und ihm dadurch kostbare Millisekunden flöten gehen. Der Roboterprogrammierer erklärt ihm: Das Anhalten kommt vom fehlenden Überschleifen in das Folgeprogramm. Der Kunde verdreht die Augen und fragt wieder: Warum hält der Roboter an? Der Roboterprogrammierer befragt das Roboterforum, ob da noch was geht.

DEF holen_B1S1( )

[...]
  
  INTERRUPT DECL 5 WHEN diSENSOR DO saugen()
  
[...]
  
    Hoehe=Stapelhoehe[1,1]

  
  ;FOLD PTP HOME CONT Vel= 100 % DEFAULT
  
  ;FOLD PTP HOME2 CONT Vel= 100 % PDAT3
  
  ;Position drueber
  ;FOLD PTP P1 CONT Vel= 100 % PDAT1 Tool[1]:Greifer Base[0]
  
  Suche()
  
  Stapelhoehe[1,1]=Hoehe
    
  ;Position drueber
  ;FOLD LIN P1 CONT Vel= 0.5 m/s CPDAT1 Tool[1]:Greifer Base[0]
  
  ;FOLD PTP HOME2 CONT Vel= 100 % PDAT4
    
  ;FOLD PTP HOME CONT Vel= 100 % DEFAULT
  
  CONTINUE
  IF (diTEILEKONTROLLE) THEN
    ablegen()
  ENDIF  
  CONTINUE ; Versuch den Vorlaufstopp zu verhindern (unwirksam)
END

DEF Suche( )
  
  INTERRUPT ON 5
  
  ;Linear relativ auf Hoehe fahren
  Verschiebung=$NULLFRAME
  Verschiebung.Z=Hoehe-XP1.Z+20
  XP2=Verschiebung:XP1
  
  
  ;FOLD LIN P2 CONT Vel= 1 m/s CPDAT3 Tool[1]:Greifer Base[0]
  
  ;FOLD LIN P3  Vel= 0.1 m/s CPDAT5 Tool[1]:Greifer Base[0]
  
  WAIT SEC 0
  
  ;nichts gefunden
  INTERRUPT OFF 5
  Hoehe=XP3.Z
END


DEF saugen()
  INTERRUPT OFF 5
  BRAKE
  
  ;FOLD 1 Sauger 2 VACUUM  GDAT1
  
  Hoehe = $POS_INT.Z
  LIN $POS_INT
  
  IF NOT diTEILEKONTROLLE THEN 
    ;FOLD SET Sauger  State= OFF  GDAT2
    Hoehe=HoeheNull
  ENDIF
  
  WAIT SEC 0.1
  RESUME
END

Konkret geht es um den Vorlaufstopp am Ende des Programms holen_B1S1(). Laut Experten-Dokumentation erfolgt am END ein Vorlaufstopp, wenn im Programm ein Interrupt deklariert wurde:

Das Stichwort "non-global" könnte dazu verleiten, ein GLOBAL davor zu setzen, aber dann habe ich ja den Vorlaufstopp in der Deklarationszeile ("has already been declared"). (Richtig?)
CONTINUE vor dem END sieht schon ziemlich verzweifelt aus und hilft hier anscheinend nicht (siehe Code). (Sollte das funktionieren?)

Da ich keinen Vorlaufstopp möchte, müsste ich den Interrupt also weiter oben in der Programmstruktur deklarieren, also ungefähr da wo der Loop (holen-ablegen) ist. Dann funktioniert aber das RESUME so nicht mehr, denn "RESUME bricht alle laufenden Interrupt-Programme und alle laufenden Unterprogramme ab bis zu der Ebene, in der der aktuelle Interrupt deklariert wurde." Und das hätte zur Folge, dass ich dann dort die Fortsetzbewegung (vom Stapel nach oben fahren) planen müsste.

Habe ich also nur die Wahl zwischen Pest (Vorlaufstopp am Ende vom Holen-Programm) oder Cholera (Fortsetzen der Bewegung nach dem Saugen im übergeordneten Programm)? Oder fällt euch noch was ein?

Wenn ich irgendwo oben falsche Annahmen getroffen habe, korrigiert mich gerne!

Gruß,

M.

Hallo,

KRC2 Version 5.2.15 mit KR6 (2x)

Nach einem Umbau der Robotergreifer habe ich an einer Pick&Place-Anlage die einzelnen Positionen angefahren und festgestellt, dass an einem Roboter alle Positionen (das heißt alle, die ich getestet habe) signifikant (ca. 25 mm) verschoben sind. Am zweiten Roboter, der quasi gespiegelt vom ersten ist, würde ich eine Änderung in Form einer Rotation um einige Grad abschätzen. Es ist zu sagen, dass die Positionen prinzipiell bedingt nicht sehr genau sein müssen, solange die Abweichung in Aufnahme- und Ablageposition gleich ist. Aber auch für diese Ungenauigkeit gibt es Grenzen.

Ich würde gerne der Ursache auf den Grund gehen und "ermittle in verschiedene Richtungen". Die Greifer wurden umgebaut, die Geometrie blieb aber (theoretisch) gleich, also auch die TCPs. Das Gewicht wurde aber verringert bzw. vom Greifer auf den Arm verlagert. Eine tatsächliche geometrische Änderung an der Anlage oder am Greifer (bzw. der Relation Greifer-Flansch) berücksichtige ich auch, soll aber nicht Teil dieses Beitrags sein.

Entsprechend der mechanischen Änderung wurden selbstverständlich auch die Lastdaten angepasst. Und ich fürchte, hier ist die Ursache zu suchen. Daher meine Frage: Kann eine Änderung der Lastdaten eine Änderung der Positionen in der genannten Größenordnung bewirken? Kann es sein, dass es sich bei zwei Robotern gleichen Modells mit baugleichem Greifer und identischen Lastkonfigurationen so unterschiedlich auswirkt? Denn bei einem Roboter habe ich eine Translation in Y-Richtung und bei dem anderen eine Rotation in A.

Gruß,

M.

Nach SI-Doku kann ANOUT nur mit Werten -1.0 bis +1.0 beschrieben werden, also geht MAXIMUM=40 nicht.

Ich nehme an, du meinst, dass die Anlage jetzt läuft und weiter laufen muss. (Wenn du Voraussetzungen schaffen kannst, Positionen im laufenden Betrieb zu ändern, ist das eine andere Fragestellung.)

Du müsstest du dir Zugriff auf die .dat - Datei verschaffen und den entsprechenden Punkt ändern. Mit WorkVisual geht das m.E. nicht (weil der Interpreter nicht aktiv sein darf zum Beispiel), aber über eine Freigabe und Öffnen im Texteditor vielleicht schon. Ist nur ein Ansatz; ob das wirklich geht, weiß ich nicht.

Ich mag es nicht besonders, wenn die Voraussetzungen einer Fragestellung hinterfragt werden, aber der übliche Hinweis, der hier hin gehört: Versuch nicht den Roboter zu verarschen, mach's ordentlich. Wäge ab (oder lass es den Auftraggeber tun): 5 Minuten Anlage anhalten zum Teachen (oder Punktdaten ändern) oder es bleibt eben bei 0,1-0,5 mm Abweichung.

Ja, das hilft schon mal. Zumindest ist damit klar, dass wir unseren Fall nicht über den Override simulieren können. Etwas Experimentieren mit verschiedenen anderen Arten des Anhaltens hat gezeigt, dass das Signal ansonsten zuverlässig kommt.
Bisher ist der kritische Fall nicht wieder eingetreten, und ich hoffe wir haben das Thema gelöst.

Dank und Gruß,
M.

Ich habe hier nur eine alte Doku von Gripper/Spottech (Version 2.3 für KUKA System Software (KSS) 5.x, 7.0). Aber da konnten auf der Konfigurationsseite für die Ein- und Ausgänge auch die Bezeichnungen der Zustände angegeben werden. (Siehe Anhang)

... wo ich so drüber nachdenke könnte das aber auch nur für die Inline-Formulare sein.

Hallo,
In einem Projekt integriere ich Roboter (KR C4, [size=1]Version gerade nicht zur Hand aber nicht älter als ein Jahr[/size]) über Profibus in eine übergeordnete Steuerung, läuft auch soweit.
In der Anwendung muss ich feststellen, dass der Roboter in Bewegung ist und bei Stopp (genauer: bei Stillstand) gegebenenfalls ein Aggregat ausschalten. In einem Fall hat das nicht funktioniert, der Roboter stand (Grund unbekannt) und das Aggregat lief weiter. Das kann auch andere Ursachen haben, weshalb ich das hier nicht weiter betrachten möchte.
Ich verwende das Signal $PRO_MOVE um festzustellen, dass der Roboter fährt. Die Suchfunktion hat mich darin bestätigt, dass das grundsätzlich das richtige Signal ist.

Laut Doku:

Zitat

$PRO_MOVE: Bedeutet, dass sich eine synchrone Achse bewegt, auch bei Handverfahren. Das Signal ist die Invertierung von $ROB_STOPPED.

Zu Referenzzwecken:

Zitat

$ROB_STOPPED: Das Signal wird gesetzt, wenn der Roboter steht. Auch bei einer WAIT-Anweisung wird dieser Ausgang während des Wartens gesetzt. Das Signal ist die Invertierung von $PRO_MOVE.

Da steht nicht sehr viel, aber ich würde doch annehmen, wenn alle Achsen stehen, ist der Ausgang $PRO_MOVE = false.
Doch dann haben wir diese Funktionalität getestet indem wir in T1 den Override auf 0% reduziert haben. Der Ausgang blieb aber true. Für mich ist das Signal also kein zuverlässiger Indikator für "der Roboter steht".
Was bedeutet denn dann "dass sich eine synchrone Achse bewegt", wenn sich gar keine Achse bewegt (OVR==0)?
Muss ich noch andere Signale auswerten?

Gruß,
M.

Vielen Dank.
M.

Hallo,
wir integrieren neue KRC4-Roboter in einer Anlage mit Profisafe. Bisher haben wir immer mit Profibus und X11 / X13 gearbeitet.
Jetzt habe ich gelesen, dass sich Profisafe und X11 ausschlössen:

Zitat von Otto Sieben

entweder ihr benutzt Safety über Profinet/Profisafe oder über X11.
Beides gleichzeitig funktioniert nicht....

Ich bin davon ausgegangen, dass zumindest die Brücken in den X11 müssen. Aber wenn "beides gleichzeitig nicht funktioniert" müsste doch auch zum Beispiel eine Unterbrechung im X11-Bedienerschutz unwirksam sein - und dann bräuchte ich die Brücke nicht.

Also meine konkrete Frage: Muss ich den X11 brücken, wenn ich die Sicherheit über Profisafe abwickle?

Gruß,
M.

Ich sehe keine Schleife um deine Fahrbewegungen. Wenn du die Funktion nur einmal aufrufst, fährt sie genau einmal die Position ab, rechnet dann wild herum und es geht wieder in Home. Rufst du die Funktion mehrfach auf? Die Variable FIRST_RUN ist nach meinem Verständnis lokal und immer FALSE.

Gruß,
M

Die Rückgabe der Funktion ist entscheidend. Es soll nichts in der Funktion bleiben, sondern die Funktion gibt einen Wert zurück, den du dann verwendest. Der Rückgabewert wird mit RETURN angegeben. Und der wird dann an der Stelle (unten im Beispiel im Main-Programm) verwendet, wo du ihn brauchst. Mal mit der auf deinen Anwendungsfall angepassten Funktion vom Polterer:

Funktion:

DEFFCT FRAME MOVETOOL() <--- Funktionsname für die Verwendung
FRAME OFFSET
OFFSET.X=$POS_ACT.X
OFFSET.X=$POS_ACT.Y
OFFSET.X=$POS_ACT.Z
OFFSET.X=$POS_ACT.A + CAM_OFFSET
OFFSET.X=$POS_ACT.B
OFFSET.X=$POS_ACT.C
RETURN TOOL_DATA[1]:OFFSET <----- Rückgabe
ENDFCT

Programmaufruf:

DEF MAIN()
INI
PTP HOME 100% DEFAULT


LOOP
Bla...bla..
mach irgendwas interessantes
...


TOOL_DATA[2]=MOVETOOL() <----- Verwendung


;mach wieder voll was geiles...
...
...
ENDLOOP


PTP HOME 100% DEFAULT
END

Alle Klarheiten beseitigt?
Wie du es verwendest (Tool oder Base) musst du dann selber gucken.

Gruß,
M.

Tatsächlich gibt es einen Unterschied zwischen KRC2 und KRC4, hier am Beispiel #INSIDE
V5.x: "Der definierte Ausgang wird gesetzt, wenn sich der TCP innerhalb des Arbeitsraums befindet."
V8.3: "Der definierte Ausgang wird gesetzt, wenn sich TCP oder Flansch innerhalb des Arbeitsraums befinden."
- bei V8.3 gilt bei #INSIDE_STOP noch zusätzlich der Handwurzelpunkt = Mittelpunkt der Achse A5

Gruß,
M.

Hallo SJX,
Das ist doch mal eine definitive Antwort, vielen Dank!
Wir hatten bestimmte Randbedingungen (Anordnung der Geräte, Anzahl der Verbindungen/Stecker, Kabellänge etc.) zu berücksichtigen und mussten daher auch verschiedene Varianten durchspielen. Glücklicherweise können wir die Greiferansteuerung auf dem Roboter montieren, was das Ganze wunderbar entflechtet. Daher können wir die von mir zuerst genannte "naheliegende" Variante umsetzen.

Dank und Gruß,
Maximus

Hallo,

Wir wollen zwei KR C2 (CP5614A2) mit einer ET200 (im Folgenden "SPS") in einem Profibusnetz betreiben. Jeder Roboter hat an seinem Greifer Module, die als Slave für den jeweiligen Roboter betrieben werden sollen. Die naheliegende Variante ist natürlich, dass die Roboter ihren Masterkreis bekommen und als Slave mit der SPS verknüpft sind.
Aus bestimmten Gründen wäre es vorteilhaft, wenn nur ein physisches Profibusnetz existierte, also nur ein lineares Netz in dem SPS, Ventilinseln, Roboter (Master und Slave!) und Greifer-Module mit einem "Draht" verknüpft werden. Per Konfiguration hätte dann jeder Master seine Slaves, es gibt keine Überschneidungen.

Ich habe hier (https://www.roboterforum.de/ro…obby-busklemmen-sps/1777/) gelesen, dass es nicht möglich sei, den Master als Roboter neben einem anderen Master im selben Netz zu betreiben.
Meine SPS-Kollegen sagen aber grundsätzlich sei Profibus dafür gemacht, dass jeder Master mit seinen Slaves kommunizieren kann; eventuell verlängere sich die Laufzeit.
Andererseits wüsste ich nicht, wie dem Mastermodul die Konfiguration des Gesamtnetzes mit den anderen Mastern bekannt gemacht werden soll, da ja nur eine .ldb für die Slaves eingespielt werden kann (korrigiert mich, wenn ich falsch liege).

Hat jemand schon Erfahrungen mit solch einer Konfiguration gemacht?

Gruß,
Maximus

Auf der KUKA-Homepage:
https://www.kuka.com/de-de/services/downloads