Beiträge von ah_robotics

Auch wir hatten schon an zwei KR5sixx-Steuerung die gleichen Probleme. Die besagte Sicherung fiel scheinbar ohne Grund aus. Allerdings blieb bei uns die ausgetauschte Sicherung heil.
Unsere Elektriker konnten keinen Fehler finden.

Seit dem habe ich immer Ersatzsicherungen mit.

Hallo,

habe folgendes Problem am Industrie-PC der KUKA-Steuerung.
Die Netzwerkkarte ist deaktiviert, im Gerätemanager ist das das Symbol für die Intel (glaube Intel PRO/1000) durchgestrichen.

Gehe ich auf Eigenschaften, ist dort zu sehen:

Zitat

Das Gerät ist deaktiviert. (Code 22)

Klicken Sie auf GERÄT AKTIVIEREN, um es zu aktivieren.

Habe ich auf GERÄT AKTIVIEREN geklickt kommt:

Zitat

Windows konnte das Gerät nicht aktivieren

Habe den Treiber de- und neu installiert, Rechner kalt gestartet, hat aber nichts gebracht.

Sieht fast so aus, als ob die Netzwerkkarte im BIOS deaktiviert wäre, aber auch das ist nicht der Fall.

Weiß jemand einen Rat?

Ciao, Andreas

[Roboter]
RobName=KR360-2 F
[Version]
Version=V5.3.8
[TechPacks]
TechPacks=Gripper-&SpotTech|UserTech|
Gripper-&SpotTech=V2.3.1
UserTech=V2.3.0

Hi,

wir haben unsere Roboterachse 6 im Programm immer wieder zurück gedreht. Man kann in zwar schon um ein Vielfaches von 360° in eine Richung drehen aber bei ca. 2 Mio grad ist dann Schluß, dann muss die Achse neu justiert werden. Überlauf.

Einfach XHOME anfahren geht nicht, weil die Steuerung sich den Umdehungsoffset merkt. Mit $AXIS_ACT.A6 kann man aber den wahren Wert der Achse 6 auswerten und dann wieder wieder zurückdrehen.

Ob sich der Umdrehungszähler einfach so zurücksetzen lässt weiß ich nicht.

Ciao, Andreas

Unsere zwei letzten Kukas waren:
Version=V5.2.14

Wäre schön wenn es bei den neuen Versionen geht

LG
Andreas

$PRO_STATE1==#P_FREE

Robotertask: Programm nicht angewählt

Wir benutzen das kostenlose RealVNC. Bei Remotedesktop sieht man nix mehr am KCP, wenn man sich mit einem Rechner einloggt. Dafür ist es wesentlich schneller, hat aber bei mir schon einige Fehlermeldung verursacht

Ich hatte auch schon einige Hänger und Fehlermeldungen, die am aktiven VNC-Server liegen könnten. Darum ist es besser ihn zu deaktivieren, wenn man ihn nicht mehr braucht. (z.B. nach der IBN)

ciao, Andreas

Hallo Hartmut,

nach SynchRobots Lösung würden ja alle Bahnen beschleunigt werden, nicht nur die für die Moving Part Bahn.
Ich habe gleich die bas.src gehackt, das ist nicht die feine englische Art, aber wir brauchen sowieso 'ne andere Lösung:

IF ACC_FACTOR>400.0 THEN

Bei $vel.ori.. ist es ja Wurscht:

IF VARSTATE ("$VEL.ORI1") <> #INITIALIZED THEN
    $VEL.ORI1=DEF_VEL_ORI1 ; swivel velocity
  ENDIF

Wenn nicht initialisiert dann default, sonst überschreibt er ja nix, zumindest nicht in der bas!

An den Lastdaten kann es liegen, die sind sehr hoch, denn unser Greifer ist sehr schwer! Aber es sind die gleichen wie bei PTP, da ist er aber wirklich superschnell!

ciao, Andreas

Versteh ich nicht! Die DEF_ -Daten sind keine Systemvariablen, nur standart-Default-Variablen!
Aus ihnen wird in Abhängingkeit mit anderen Vorgaben in der bas.src die Systemvariablen $vel.. und $acc.. beschrieben.
Wenn ich die gleich die $vel.ori1/2 und $acc.ori1/2 auf 400 und 800 setze (höher gehts nicht!) hat das doch die gleiche Wirkung, oder?

DEF  ACC_CP (ACC_FACTOR :IN )
  REAL ACC_FACTOR ; [%]


  IF ACC_FACTOR>100.0 THEN
    $ACC.CP=DEF_ACC_CP
    $ACC.ORI1=DEF_ACC_ORI1
    $ACC.ORI2=DEF_ACC_ORI2
  ELSE
    $ACC.CP=DEF_ACC_CP*ACC_FACTOR/100.0
    $ACC.ORI1=DEF_ACC_ORI1*ACC_FACTOR/100.0
    $ACC.ORI2=DEF_ACC_ORI2*ACC_FACTOR/100.0
  ENDIF
END

DEF  VEL_CP (VEL_VALUE :IN )
  REAL VEL_VALUE ; [m/s]
  INT I


  IF VEL_VALUE>DEF_VEL_CP THEN
    $VEL.CP=DEF_VEL_CP
  ELSE
    $VEL.CP=VEL_VALUE*DEF_VEL_FACT
  ENDIF


  IF VARSTATE ("$VEL.ORI1") <> #INITIALIZED THEN
    $VEL.ORI1=DEF_VEL_ORI1 ; swivel velocity
  ENDIF
  IF VARSTATE ("$VEL.ORI2") <> #INITIALIZED THEN
    $VEL.ORI2=DEF_VEL_ORI2 ; rotation velocity
  ENDIF


  FOR I=1 TO  $EX_AX_NUM
    $VEL_EXTAX[I]=DEF_VEL_PTP
  ENDFOR
END

ciao

Im schlimmsten Fall feuert die Strom-Überwachung der Motoren dann die Antriebe raus. Irgendwo sind die in den Maschinendaten hinterlegt. Theoretisch kann man die ändern, dann kann es aber passieren, dass so ein Servo mal durchschmort :(.
Die Garantie dürfte sich dann auch erledigt haben ;)!

Die Bewegungsüberwachung schaut ja nur, wo muss ich sein, und wo bin ich. Was ich auf den Servo draufgebe, muss als Weg auch über den Geber wieder zurück kommen. Wenn die Toleranz zu groß ist, dann aus!
Ist ähnlich wie beim FI!

ciao, Andreas

Bei den ersten 2 Teilen ist es die 6. Achse, denn nur diese wird da gedreht. Nur bei den 3. Teil kommen Achse 5 und 4 dazu. Die anderen Achsen bewegen sich nur wenig.
Das Phänomen ist aber bei allen 3 Teilen das gleiche!

ciao, Andreas

Hallo,

leider geht die Langtextauflösung bei Signal-Integer Variablen auf der Kuka-Roboter-Steuerung nicht.

DECL INT i_eingang=15  ;IN $CONFIG.DAT

Im Programm dann:

WAIT FOR $IN[i_eingang]

ODER:

SIGNAL i_eingang $IN[15]

WAIT FOR i_eingang

Robotersteuerung zeigt an:

WARTE AUF EINGANG i_eingang

Verwende ich aber die direkte Zahl, wie auch im Inline-Formular verwendet:

WAIT FOR $IN[15]

Da zeigt die Robotersteuerung den Langtext an.

Gibt es inzwischen bei der 5er Steuerung eine Möglichkeit den Langtext so anzuzeigen? Gibt es da vielleicht Technologie-Pakete?
Bei der 4er Steuerung gab es einen Registry-Eintrag unter Windows, der den Langtext auch bei Variablen ausgegeben hat, der jetzt leider auf der neuen Steuerng nicht mehr funktioniert.
Das Office Lite 4 hat das generell gemacht, zumindest bei mir hier!

Ich möchte aber nicht alle Variablen in den Waits durch Zahlen oder Inline-Formulare ersetzen!

ciao und danke, Andreas

Hallo,

wir brauchen eine Option, die die Bahngeschwindigkeit $vel.cp als Priorität setzt. Das heißt, der Roboter sollte seine Bahn versuchen immer mit konstanter Geschwindigkeit zu fahren.
Ich kenne diese Option von anderen Roboter-Herstellern, wie z.B. Stäuli.

danke und ciao, Andreas

Habe $VEL.ORI1, $VEL.ORI2, $ACC.ORI1 und $ACC.ORI2 auf 400 gebracht. Hat leider nichts genützt! Er verringert seine Bahngeschwindigkeit in den Kurven immer noch drastisch.

Nein leider nicht. Ich kann es drehen und wenden wie ich will. Eine Koordinade zeigt immer in die falsche Richtung! Als würdest du den Roboter im Spiegel verfahren, echt irre!

Das muss auch so sein, weil sich jetzt alles im Toolkoordinatensystem abspielt, der KUKA verändert dynamisch sein TCP!
Und wenn ich mein TCP von NULL(FRAME ) auf z + 100, also vom Flansch wegsetze, fährt der Flansch genau 100mm in die andere Richtung. Das Toolkoordinatensystem ist invertiert!

Kuka hat es sich hier einfach gemacht!
Mit diesem Trick kann man auch andere Roboter mit extern TCP fahren. Man ändert einfach statt den Positionsdaten die Tooldaten. Das geht aber nur, wenn der Roboter einen Tool-Wechsel verschleifen kann. Sonst bleibt er bei jeder Position stehen. Die V+ Steuerung von Stäubli/Adept kann das leider nicht, aber die neue Stäubli CS8 angeblich schon.

ciao, Andreas

Oh danke!

Der KUKA akzeptiert Beschleunigungswerte jenseits der 100%?
Im schlimmsten Fall regelt er ja sowieso ab, hoff' ich mal!

Ich werd's mal testen.

ciao, Andreas

Man kann doch das FOERDERER-Programm in der schon besteheden SPS.SUB einfach extern aufrufen.
Also nicht SUB sondern foerderer.src. Da kann man gleich ein foerderer.dat mit erstellen und schon hat man lokale Daten.

Hallo,

... ist er ja gar nicht, aber ich habe folgedes Problem.

Wir müssen Teile im Greifer an einer Rolle vorbeifahren, bewegtes Werkstück. $IPO_MODE = #TCP
Alles klappt schön schnell, bis der Roboter anfängt das Teil zu drehen. Dann reduziert er seine Bahngeschwindigkeit sehr drastisch und fängt eben an das Teil korrekt, aber gemächlich zu drehen! Das ist aber nicht gut!

Nun habe ich die Schwenkgeschwindigkeit und die Drehgeschwindigkeit ($VEL.ORI1 und $VEL.ORI2) auf 400 grad/s erhöht. Jetzt geht es etwas besser. Leider kann ich keinen größeren Wert als 400 grad/s angeben. Default sind 200 grad/s!

Hat jemand eine Idee wie ich das noch schneller bekomme?

danke und ciao, Andreas

Danke für die schnelle Antwort.

Du meinst das auf KRC\UTIL\CHG_POS\

Wäre aber schön, wenn es im Befehlsumfang eine Funktion dafür geben würde.

ciao, Andreas

Hallo,

hat jemand hier Erfahrungen mit RobotWorks in Verbindung mit KUKA? Export von Extern-TCP-Daten?

Die Daten kommen nur in Extern-Base orientiert aus dem Rechner. Bei Extern-TCP beziehen sich meine Positions-Daten ja nicht auf WOLD sondern auf TOOL und sind somit gespiegelt (KUKA).
So kann ich sie nicht verwerten :(!

Obwohl in RW Extern-TCP angewählt ist (P wie moving Part!!!), und convert mit F-Tool.
Im Rechner geht auch alles simuliert!

ciao, Andreas

Hallo,

wir haben folgendes Problem mit Extern-TCP.

Unsere BASE, also das externe TCP, ist auf einer Rolle, an der der Kuka das Teil im Greifer bahnbezogen entlang fahren muss.

Allerdings sind die Positionsdaten bei Extern TCP anders als bei Extern BASE.
Das Koordinatensystem ist gespiegelt, weil der KUKA wahrscheinlich bei feststehenden Werkzeug im Grunde nicht seine Positions-Daten zu verändern scheint, sondern seine eigentliche Tool-TCP Daten. Der Flange-Urspung wird also einfach auf die Rolle projiziert.

Die Tool-TCP Daten beziehen sich aber nicht auf World, sondern auf den Flange, wie das bei TOOL-Daten ja so üblich ist.

Mein Ursprung ist aber meine Rolle, die mit WORLD verwandt ist. Diese bezieht sich jetzt aber auf das Toolkoordinatensystem und steht gespiegelt im Raum!

Unsere Positions-Daten bekommen wir von einer Simulations-Software (RobotWorks), die eigentlich die Daten schon fertig gespiegelt rausbringen müsste, wenn Extern-TCP angewählt ist. Tut sie aber nicht im Falle KUKA!

Gibt es eine Möglichkeit, mein Koordinatensystem wieder „umzuspiegeln“? Oder gibt es Berechnungen, die meine Extern-BASE Daten in Extern-TOOL Daten umkonvertieren können?

Bei anderen Robotern kenne ich die Inverse-Berechnung von Positionen. Damit kann ich z.B. auch Positionen auf ein anderes TOOL umrechnen.

BEISPIEL:

TOOL: werkzeug

MOVE POS1

ist z.B. die gleiche Position wie

TOOL: NULL

MOVE POS1:INVERSE(werkzeug)

Wegen dem eigentlichen „Problem“ mit RobotWorks habe ich noch einer anderen Rubrik eine Frage laufen.

danke und ciao, Andreas