Beiträge von PAW

Danke, Leute,

so wie von titan72 beschrieben, funzt die Sache. So hat die KUKA-Hotline immer was zu tun, wenn solche Sachen geändert werden.

an alle Helfer

Gruß

PA

Hallo, Leute,

danke für die Antworten.

@titan72: DeviceNet funktioniert jetzt. Telnet geht trotzdem nicht.

SJX: Habe es mit dem Vorsatz exec versucht, Fehlermeldung wie gehabt!

Ist ja alles nicht so schön.

Hat jemand KRLXML im Einsatz und könnte mal einen Telnet-Befehl absetzen wie von SJX angegeben? Vielleicht verhindert KRLXML ja die Verwendung von Telnet.

Danke schon im voraus.

Gruß

PA

Hallo, Leute,

zur Fehlersuche der DeviceNet-Konfiguration führe ich telnetk 192.0.1.1 aus und gebe z. B. ein:dnWho oder dnLookIO ...

Telnet gibt zurück undefined symbol: dnWho bzw. nach dem Doppelpunkt meine Eingabe.

Was läuft hier schief? Ich habe diese Befehle schon jahrelang benutzt.

Version KRC2, 5.5.10, BOF 2.0.6.6B65.

Auf dem System ist noch KRCXML installiert.

Danke für Infos

Gruß

PA

Hallo, marka,

ich vermute, dass das loop an der falschen Stelle steht. Erzeuge einfach mal ein neues Programm mit einem Template und füge im Expertenmodus vor dem END ein:

loop

endloop

END; das ist das vorhandene END

Kommt dann die Fehlermeldung noch?

Gruß

PA

Hallo,

wir wollen mittels KRLXML Arrays in der Form versenden, dass wir in eine Real-Variable (Z.B. xwert) nacheinander mehrere Werte schreiben, die im zugehörigen Puffer gesammelt werden sollen. Wenn das Array komplett ist, wird dies mit dem Setzen einer weiteren Variable mitgeteilt. Die zu erwartende Anzahl der Werte für xwert variiert. Das ganze soll etwa so aussehen:

1. Senden: xwert=1
2. Senden: xwert=3
3. Senden: xwert=8
4. Senden: xwert=11

Wenn das Array-Ende angekündigt ist mit Setzen der oben erwähnten weiteren Variable, soll die KUKA-Steuerung den Puffer von xwert auslesen und in ein internes Array übertragen. In der Dokumentation habe ich gelesen, dass ein Ringpuffer verwendet wird, für dessen Größe man je Variable einen Wert zuweist.

Mir stellt sich nun die Frage, ob nach Auslesen dieses Ringpuffers der nächste neue Wert für xwert wieder ab Pufferposition 1 geschrieben wird oder ob dieser Puffer von 1 bis Pufferende gefüllt wird und dann wieder bei 1 anfängt?

Mit der beschriebenen Aktion wollen wir so etwas wie dreidimensionale Arrays erzeugen, ohne einen wahnsinnig großen Variablenwust zu erzeugen. Die Anzahl der Werte für beispielsweise xwert kann 30 und mehr sein.

Hallo, Gladiator,

wenn der Punkt in einer Programm-Datenliste (also nicht in der $config.dat) steht, kann man sich die Variable nur anzeigen lassen, wenn das zugehörige Roboterprogramm angewählt ist, sonst kommt es zu der von Dir beschriebenen Meldung. Ändern kann man den Punkt, indem man am einfachten <Punktname>.x f. Änderung X etc. in die Variablenanzeige schreibt.

Gruß

PA

Hallo, blender!

HW_Inf.ini

COM1=DISABLE ;WIN95 mouse
COM2=ENABLE ;Vx Works <= ist so richtig
COM3=DISABLE ;not implemented
COM4=DISABLE ;not implemented

Serial.ini

[COM2]

BAUD=9600
CHAR_LEN=8 ;7,8
STOP_BIT=1 ; 1,2
PARITY=2 ;EVEN=2 , ODD=1, NONE=0

PROC=1 ; 3964R=1, SRVT=2, WTC=3, XONXOFF=4

Mit diesen Einstellungen laufen unsere Roboter seit Version 1.1.10. Wir verwenden lediglich eine höhere Baudrate, die unter [COM2] geändert wird. Unter [3964R] haben wir einige Werte etwas erhöht, spielt aber bei wenigen Daten keine Rolle.

Gruß

PA

Hallo, Zorro64,

ich persönlich halte die monatliche Überprüfung der Software-Endschalter für völlig überflüssig. Es handelt sich hierbei um eine Software-Lösung wie die gesamte Steuerung. Ich habe noch nie erlebt, dass ein vor Jahren gesetzter Software-Schalter plötzlich nicht mehr funktioniert. Überprüfen sollte man meiner Meinung nach die Software-Endschalter nach einem Update des KUKA-Software-Standes, wenn man automatisch alle Dateien konvertieren lässt.. Vor einigen Tagen bin ich selbst mit einem Roboter versehentlich in einen vor fast 5 Jahren gesetzten Software-Endschalter reingefahren. Wenn man Software-Endschalter in Frage stellt, muss man das ganze System in Frage stellen. Regelmäßig überprüfen sollte man die Notaus-Funktion, die ist Hardware.

Gruß

PA

Zitat von $CYCFLAG

Vielleicht möchten sich noch andere Outen!

Hallo,

dieses Forum sollte doch für Fragen und Antworten benutzt werden. Nimm es bitte nicht persönlich, wenn ich sage, dass ich diese Negativ-Beurteilung von KUKA hier nicht so schön finde. Die "Next-Generation" kenne ich, wie die meisten anderen, nicht. Vielleicht könntest Du uns mitteilen, was das ist. Ich nutze dieses Forum gern, um was dazuzulernen.

Gruß

PA

Hallo,

man müsste ein Musterwerkstück, z. B. Deinen gedachten Würfel, mit einem frisch justierten Roboter abfahren und für X, Y, u. Z die Koordinatenwerte f. X, Y u. Z aufnehmen und in 1 oder mehrere Variable schreiben. Beim automatischen Vermessen dann IST u. SOLL vergleichen und die Abweichung ermitteln Das automatische Vermessen muss dann per Suchfunktion mittels Interrupt erfolgen.

Gruß

PA

Hallo,

falls Du nur ein KCP vor Ort hast: beleuchte das dunkle KCP mal mit einer kräftigen Taschenlampe. Wenn Du dann schwach etwas siehst, ist die Hintergrundbeleuchtung vom KCP nicht OK.

Gruß

PA

Hallo,

von KUKA kann man zum Nachrüsten einen X11-Stecker mit zusätzlichen 24V (1* 6A, 1*4A) kaufen. An diesem Stecker, der gegen den im Schrank eingebauten Stecker ausgetauscht wird, hängt eine zusätzliche 4adrige Leitung mit einem weißen Stecker (Amphenol oder so was). Außerdem wird, meine ich, ein Adapter mitgeliefert. Links neben dem PM600-Netzteilist ziemlich weit oben eine weiße 3adrige Steckverbindung mit blauen Litzen dran. Dazwischen wird dieser Adapter gesteckt. Das ist die elegante Methode. Ansonsten muss man sich über Lüsterklemmen an diesen Litzen die 24V holen. Da weiß ich im Moment aber nicht mehr, welche Feinsicherungen genau an dem PM-660-Netzteil dazugehören, um das zu testen. Diesen Adapter kriegt man, denke ich, von einem Tag auf den anderen.

Gruß

PA

Hallo,

aufgrund der 1. Frage

kann es sein, dass man in KRL (4.1) bei:
INTERRUPT DECL Prio ....

konnte ich nicht den Eindruck haben: Na supi, das ist mir auch klar...

Gruß

PA

Hallo,

ich glaube, wenn nicht in Automatik extern gearbeitet wird, ist die SAK-Fahrt nur mit ptp XHOME durchgeführt, nicht mit einem beliebigen anderen Punkt.

Gruß

PA

Hallo,

einen Interrupt deklarie=rt man so: Interrupt decl <Nr. 1 ... 32> when ..., nicht zu verwchseln mit
trigger WHEN distance = <Schaltpunkt auf der Bahn> delay = <> DO UP () prio = <Nr 1 ...39, 81...128>

Gruß

PA

Hallo,

die Stellung der Achse steht in $axis_act.a1. Um die SAK-Fahrt zu unterdrücken, setzt man
XHOME=$axis_act
ptp XHOME

Der Roboter macht dann die SAK-Fahrt auf der Stelle. Ganz weglassen kann man die SAK-Fahrt nur in der Betriebsart "externe Automatik", warum auch immer.

Gruß

PA

Hallo,

ich habe feststellen müssen, dass man zwar im Programm-Test schreiben kann :If Eingangxxx THEN ..., bei der Interrupt-Deklaration muss man aber schreiben ... Eingangxxx==true, damit das akzeptiert wird. Es ist dabei egal, ob symbolische Namen oder $IN[] benutzt wird. Ich habe mich vor Jahren damit abgefunden.

Gruß

PA

Hallo, Bora,

ich habe noch mal meine Unterlagen zum Thema durchwühlt, finde aber leider keine andere Lösung als die bereits kommunizierten. Wenn man die externen Achsen in ihrer Gewschwindigkeit unabhängig voneinander bewegen will, müsste man in jedem asyptp-Befehl nur jeweils 1 Achse asynchron bewegen. Da aber nur 3 aufeinanderfolgende Befehle erlaubt sind, hat man wg. der oben besprochenen Abfragen immer Stopper in der Löffelbewegung, selbst dann, wenn man die Löffel in der SPS.SUB programmiert (wäre nur nötig, wenn der Roboter sich parallel zu den Löffeln kontinuierlich bewegen soll).

Meines Erachtens kann man die Löffel nicht als externe Achsen laufen lassen, sondern müsste sie parallel mit einer anderen Steuerung (KUKA hat auch eine Soft-SPS, die kenne ich aber nicht) laufen lassen und über Handshakes mit dem Roboter handeln. Mehr fällt mir dazu leider auch nicht ein. Die Abtrennung der Löffel als externe Achsen ist jetzt wahrscheinlich nicht mehr möglich, oder?

Gruß

PA

Hallo, bora,

im Prinzip wäre das so, wie von Dir beschrieben. Um einen flüssigen Lauf hinzukriegen, könnte man den Roboter nicht mit nur einem Löffel den 1. Punkt anfahren lassen und vom 2. bis 6. Punkt (beispielsweise) den Roboter mit beiden Löffeln, den 7. Punkt mit Roboter und nur dem 2. Löffel? Wäre wg. der von Dir geforderten unterschiedlichen Löffelgeschwindigkeiten nicht einfach, aber im Asynchronmodus kriegt man das wegen der nur 3 erlaubten aufeinanderfolgen Asynchronbewegungen noch schlechter hin. Wenn der Roboter sich bei aufeinanderfolgenden Bewegungen gar nicht bewegen muss, kann man das in der Bewegungsstruktur ja auch weglassen:

Vielleicht fällt eine Hilfestellung incl. des Weglassens unmöglicher Ideen leichter, wenn Du die Aufgabenstellung kurz beschreibst. In Deiner 1. Frage beschreibst Du, dass abwechselnd 1 von 2 Löffeln bewegt wird, jetzt sind es immer beide???

Gruß

PA

Stethi,

die Information mit dem Single-Brake-Modul habe ich vor gut 3 Jahren von KUKA aufgrund des von mir geschilderten Problems (2 externe Achsen zusammen asynchron verfahren) in diesem Betreff weiter oben schriftlich bekommen (damaliger SW-Stand war 4.1 auf KRC2). Bora kann für diese ggf. fehlerhafte Information nix. Vielleicht hat KUKA inzwischen was unternommen.

Gruß

PA