Beiträge von PAW

Diesen Timer kannte ich auch noch nicht. Wie hast Du den gefunden?

PA

Hallo hermo,
danke für die Info. Wir haben erst 2010 mit FANUC angefangen, davor hatten wir nur einen Roboterlieferanten.

Gruß

PA

Die Meldung

*** Translation successful, 414 bytes of p-code generated, checksum 23472. ***
Build fehlgeschlagen: ????-820 $ 4A0F34, no message found
0x70044 - File sinus.pc

erscheint, wenn im Variablenteil z. B. die Größe von Arrays geändert wurde. Vor dem Kompilieren im TeachPendant von Roboguide das Programm UND die zuhörige Variablenliste löschen. Dann sollte beim nächsten Kompilieren die Meldung weg sein.

Gruß

PA

Ich verwende OLPCPRO zur Offline-Programmierung. Vor dem Download der Programme muss man nun zuerst, ich sage mal, den realen Roboter bei OLPCPRO anmelden. Beim allerersten Roboter hat das mit dem Programm FRADDRobot auch funktioniert. Den Hostnahmen "Robot" hatte ich bei der TCP/IP-Einstellung der IP-Adresse unverändert gelassen.

In der Roboter-Liste von OLPCPRO tauchte dieser Roboter sowohl mit seiner IP-Adresse als auch mit seinem Host-Namen auf. Eigenartigerweise hat die Verbindung nur funktioniert, wenn ich den Host-Namen anklickte, bei Auswahl der IP-Adresse kam nach einiger Zeit die Fehlermeldung "Connection closed, ... FTP ..." (genaue Meldung weiß ich nicht mehr).

Jetzt kommt das eigentliche Problem.
Für einen neuen Roboter habe ich in OLPCPRO eine neue Zelle erstellt, der Roboter hat eine andere IP-Adresse als der erste Roboter, den Host-Namen hatte ich zunächst nicht verändert. Die oben beschriebene Problematik hatte ich bis jetzt schon wieder vergessen. Nach der Anmeldung wie oben beschrieben hatte ich in meiner Roboterliste die neue IP-Adresse mit drin. Die Roboter-Auswahl per IP-Adresse wie oben bringt den beschriebenen Fehler, die Auswahl "ROBOT" (Host-Name) lässt das Programm nach dem ersten Roboter suchen, der bei dieser Anlage natürlich nicht da ist.

Die alleinige Änderung des Host-Namens brachte nix, da FRADDRobot bei schon verwendeter IP-Adresse einen Laufzeit-Fehler bringt. Ein Versuch mit neuer IP-Adresse und Host-Namen <> "ROBOT" brachte auch nix. Die neue IP-Adresse wurde in die Auswahl-Liste eingetragen, als Host-Namen gibt es weiterhin nur "ROBOT".

Jetzt die Fragen:
1. Wie kann ich den nutzlosen Eintrag wieder löschen, um die IP-Adresse des Roboters weiterhin benutzen zu können und das Einfügen dieses Roboters ohne Laufzeitfehler wieder zu probieren (ich kann nur die 1 vorgeg. IP-Adresse benutzen)?

2. Welche Einstellungen müssen am Roboter und bei OLPCPRO genau gemacht werden, damit ich mehrere Roboter verwalten kann? Am Roboter habe ich nur unter TCP/IP die IP-Adresse und den Host-Namen oben rechts geändert.

Mit dem Internet-Explorer meines Notebook kann ich sowohl per http als auch per ftp auf den Roboter zugreifen.

Gruß

PA

Vielleicht hätte ich dazuschreiben sollen, dass ich ebenfalls die Steuerung R30iA meinte. Ich kenne aber keine andere.

Nur aus Neugier: wofür ist die Steuerung RJ3?

Gruß

PA

Hallo, WolfHenk,

seit wann ist RUN ... eine kostenpflichtige Systemoption? Wir haben bisher nix dafür bezahlt. Ich werde das für einen neuen Roboter brauchen, den ich in den nächsten Wochen in Betrieb nehmen und programmieren muss.

Gruß

PA

Hallo Chili1886,

TP-Prog. u. Karel-Prog. können Werte nur über die Register austauschen. Ein Prog. mit TP für einen Durchlauf starten, wobei das aufrufende TP-Prog. bis zum Ende des aufgerufenen Prog. wartet, mit

1: CALL Beispiel;

aufrufen, für Parallelbetrieb von TP und Karel (so mache ich das immer, daher weiß ich nicht sicher, ob ein TP ein Karel mit "CALL" aufrufen kann)

1: RUN Beispiel;

Das TP-Prog. läuft dann natürlich weiter, wenn es nicht auf PAUSE kommt.
In Deinem Fall wäre die 2. Variante bestimmt nicht schlecht. Du benutzt ein Register, um dem Karel mitzuteilen, welche Routine es verwenden soll, und ein Register, um dem Karel die Nr mitzuteilen.

Das Karel in einer Dauerschleife laufen lassen mit einem DELAY 10 darin, um die Systemressourchen nicht zu überlasten. Das Karel guckt mit GET_REG(10,regflg,ivar,rvar,regstat), was in Register 10 steht.

Wenn der Registerwert ein Integer ist, steht der Registerwert in ivar, und regflg ist false. In Abhängigkeit dieses Registerwertes kann die gewählte Routine weitere Aktivitäten durchführen.

Ich hoffe, das hilft weiter.

Gruß

PA

Nummer1

Hallo heini0707,

die Nummer mit 2 Sensoren mache ich, wenn solche da sind. Die Suchaktion mit Saugern war nur 1 Beispiel, vielleicht ein unglückliches (da habe ich sogar für die Suche aus großer Höhe einen Vorsensor). Es gibt einen weiteren Suchmodus, bei dem der Roboter gelegentlich vor einem Stapel herunterfahren muss, dessen Höhe variiert und nicht immer bekannt ist. Bei dieser Aktion habe ich nur unten am Greifer einen nach vorn schauenden Lichttaster. Wenn die Oberkante des Stapels dicht über dem Boden ist, muss das Bremsen schnell gehen.

Aber während ich das schreibe, denke ich, dass die Suchfahrt in einem solchen Fall in eine größere und eine bedeutend kleinere Bahn aufgeteilt werden muss, damit das Ganze flott geht. Das mit der verringerten Beschleunigung probiere ich auf jeden Fall aus.

Gruß

PA

Hallo, rob76,

das "normale" skip ist so träge, dass der Roboter nach Eintritt des Ereignisses noch ca. 50 mm weit ausläuft, bis er zum Stillstand kommt. Deshalb ist diese Suchfunktion nicht geeignet, wenn der Greifer von oben auf das Objekt der Begierde fährt, um die Oberfläche beispielsweise mit Saugern zu finden. Ich werde deshalb das Anhängen von ACC ausprobieren, werde aber erst in einigen Wochen dazu kommen. Dann kann ich das Ergebnis mitteilen. Danke.

Gruß

PA

Hallo, rob76,

hier ein kurzes Beispiel:

1: SKIP CONDITION R[199]=2;
1: L PR[62] 100 mm/sec FINE SKIP, LBL[695], PR[10]=LPOS;

Gruß

PA

Hallo, Leute,

wenn ich zum Suchen eines Teils Fine Skip auf einen Sensorpegel verwende, wird der Roboter (R2000 iB mit aktueller Steuerung) bei ansprechen des Sensors so heftig gebremst, dass man Angst um die Mechanik kriegt. Kann man die entsprechende Bremsrampe etwas sanfter machen?

Gruß

PA

Hallo,

nach meinen Erfahrungen muss man immer genau auf das NUT x.x.x in der Achs-Konfiguration schauen. Für Achse 6 ist der letzte Wert wichtig (NUT x,x,1 f. Achse 6 >180°, NUT x,x,0 f. Achse 6 180 ... -180°, NUT x,x,-1 f. Achse 6 <-180°). Mit Achse 6 meine ich die Flanschachse, FANUC nennt das beim 4-Achs-Roboter glaube ich J4, KUKA bleibt bei Achse 6. Vielleicht ist der Vorpunkt ungünstig in der Drehung? Aber ich denke eher, dass es an NUT x,x,xliegt. Vielleicht sind die Werte für die letzte Achse beim 4-Achser anders gelegen als beim 6-Achser.

Gruß

PA

Hallo, WolfHenk,

DELAY ist offenbar nicht das Problem. Das Programm kommt in die READ-Funktion und bleibt da, weil ein byte wohl unvollständig ist und damit das Ende fehlt. Das Ganze ist bedingt durch elektrische Störungen.

Ich habe testweise einen Abstandssensor über die gleiche Schnittstelle angesprochen, und zwar 10000 Mal. Ein Auslesevorgang dauert ca. 24 ms, das System war entsprechend ca. 4 min damit beschäftigt, das Programm lief komplett durch und wurde ordnungsgemäß beendet.

Gruß

PA

Hallo, Christian,

ich würde die Pyramide etwa wie folgt programmieren:

&ACCESS RVP
&REL 232
&PARAM TEMPLATE = C:\KRC\Roboter\Template\ExpertVorgabe
&PARAM EDITMASK = *
DEF Zylstapeln( )
FRAME myframe
INT reihe
int reihenzahl; Anzahl Reihen, hier 4
int zylinderzahl; Zylinder je Reihe, je Reihe einer weniger
int zylindernum; aktueller Zylinder in der Reihe
int ZYLINDER_D; Konstante Durchmesser
int ZYLINDER_H; Konstante Hoehe des Zylinders

$VEL_AXIS[1]=100
$VEL_AXIS[2]=100
$VEL_AXIS[3]=100
$VEL_AXIS[4]=100
$VEL_AXIS[5]=100
$VEL_AXIS[6]=100

$ACC_AXIS[1]=100
$ACC_AXIS[2]=100
$ACC_AXIS[3]=100
$ACC_AXIS[4]=100
$ACC_AXIS[5]=100
$ACC_AXIS[6]=100
$VEL.CP=1.5
$ACC.CP=1.5
$VEL.ORI1=1.5
$VEL.ORI2=1.5
$ACC.ORI1=1.5
$ACC.ORI2=1.5
$ADVANCE=3
$BASE=BASE_DATA[1]; das muss man nicht jedes Mal wiederholen
$TOOL=TOOL_DATA[1]; das muss man nicht jedes Mal wiederholen

reihenzahl=4
ZYLINDER_D=40
ZYLINDER_H=25
reihe=1

Repeat

PTP XP1
$OUT[1]=FALSE
$OUT[2]=TRUE
PTP XP2
$OUT[2]=FALSE
$OUT[1]=TRUE
;FOLD WAIT Time= 0.2 sec;%{PE}%R 5.2.34,%MKUKATPBASIS,%CWAIT,%VWAIT,%P 2:0.2
WAIT SEC 0.2
;ENDFOLD
PTP XP1
$APO.CPTP=50
PTP XP3 C_PTP
PTP XP4 C_PTP
PTP XP6 C_PTP

zylinderzahl=reihenzahl+1-reihe
zylindernum=1

repeat
droppos=XP5
myframe=$NULLFRAME; im folgenden wird der 1. Zylinder mit seinem Mittelpunkt auf $NULLFRAME.x gesetzt, in der Hoehe auf$NULLFRAME.Z
myframe.X =-(zylindernum-1)*ZYLINDER_D+(0.5-0.5*reihe*ZYLINDER_D); ab der 2. Reihe Verschiebung X um halben Durchmesser
myframe.Z =(reihe-1)*ZYLINDER_H

$APO.CDIS=20
LIN myframe:droppos
LIN_REL{Z-26}

$OUT[1]=FALSE
$OUT[2]=TRUE

LIN_REL{Z 20}
$OUT[2]=FALSE
$OUT[1]=TRUE

PTP XP6 C_PTP
PTP XP7 C_PTP
PTP XP3 C_PTP

zylindernum=zylindernum+1

UNTIL (zylindernum > zylinderzahl)

reihe=reihe+1
UNTIL (reihe>4)

PTP HOME
end

Generell würde ich Schleifen, IF/ELSE/ENDIF immer mit Einrückungen machen, damit man bei Fehlersuche besser zurechtkommt. Ich habe den obigen Vorschlag auf die Schnelle gemacht und habe keinen KUKA zum probieren zur Hand, deshalb keine Garantie auf Fehlerfreiheit. Ich wüde als Bezugspunkt für die Zielrechnung auch eher eine Grundpos der Pyramide definieren, mit $NULLFRAME habe ich mehr als 10 Jahren KUKA-Programmierung nie gearbeitet.

Gruß

PA

Liebe Gemeinde,

wir benutzen eine serielle Schnittstelle aus dem FANUC-Schrank jetzt, um eine Motorsteuerung anzusprechen. Offenbar verursachen größere Motorströme Störungen auf der seriellen Schnittstelle (diese Störungen sind elektrischer Natur und sollen von uns selbst eliminiert werden, sind hier also nicht das Thema).

Das Problem ist, dass diese Störungen von der FANUC-Steuerung offenbar teilweise für bits gehalten werden und die Funktion BYTES_AHEAD "annehmen lassen", dass mehr Bytes als tatsächlich vorhanden sind. Die Bytes sind aber teilweise unvollständig.
In der ersten Zeit unserer Tests ist mein Kommunikationsprogramm nach Prüfung mit BYTES_AHEAD und Ergebnis, dass mind. 1 Byte vorhanden, in der READ file ()-Funktion hängengeblieben und konnte mit drücken der ABORT-Taste beendet werden.

Inzwischen hängt sich irgendetwas bei diesem Fehler derart auf, dass die Anzeige auf dem TeachPendant einfriert und ABORT nicht mehr geht, weil keine Tastenfunktion mehr reagiert. Fehlersuche mittels FANUC-Hotline ergab, dass der Speicher physikalisch in Ordnung ist und die CPU noch läuft, nachdem der Fehler aufgetreten ist. Die Hotline vermutet nun, dass etwas mit dem sogenannten Kommunikationsspeicher nicht stimmt. In der Doku steht, dass das TeachPendand ebenfalls an einer seriellen Schnittstelle hängt, so dass dessen Verhalten in Bezug auf den Kommunikationsspeicher erklärlich ist.

Was kann man in Sachen des Kommunikationsspeichers unternehmen? Rekonfigurieren, ... ?

Vielen Dank für Hilfe.

Gruß

PA

Hallo,

interessant wäre die Größe der Teile, also Länge, Breite, Höhe, dann könnte man diese als Variablenwerte nehmen und direkt damit rechnen. Das wäre übersichtlich, zumindest bei Erhöhung der neuen Z-Werte bei der Folgelage.

Gruß

PA

Der Port kann sogar 38400. Das Gespräch gestern mit FANUC und die Konsante BAUD_9600 ließ vermuten, dass da nicht mehr ist. Die Baudratenerhöhung scheint aber nix zu bringen. Wir müssen in schneller Folge Messungen machen, deshalb öffne ich den Port 1 Mal zu Beginn der Mess-Schleife, in jedem Schleifendurchlauf wird dann CLR_IO_STAT (file) gemacht, dann gelesen.

Unter Verwendung von $fast_clock (incrementiert inzwischen alle 2 ms um 1) habe ich f. 15 byte zwischen 40 u. 48 ms bei 9600 baud , der Maximalwert ist auch bei 38400 Baud nicht kleiner. Es wurden je 3 Zyklen mit jeweils 20 Messungen gemacht, also 60 Messungen mit 9600 Baud, dann 60 Messungen mit 38400 Baud.. Der Sensor schreibt Daten, wenn er hardwaremäßig getriggert wird. Nach Messung, also vor Rückkehr an den Schleifenanfang, habe ich den nächsten Triggerpuls f. die Folgemessung und damit die nötige Pause (da PULSE ohne nowait), um die Messungen durchzukriegen. Ohne Pause verharrt das System nach wenigen Messungen in READ ... und macht nicht mehr weiter. Bei diesen Tests lief kein weiteres Programm.

Bei XML-Kommunikation ist das übrigens genauso, ohne einige Delays läuft eine XML-Kommunikation nicht zuverlässig.

Gruß

PA

Das Problem hat sich erledigt. Den benutzten Port unter MENU > SETUP > PortInit auf [no use ] setzen, dann spielt XONOFF etc. keine Rolle.

GET_PORT_ATR funktioniert wahrscheinlich nicht (Auskunft von Fanuc-Mitarbeiter war, dass nicht alle Funktionen wirklich gehen, deshalb darf man wohl davon ausgehen, dass diese Funktion auch nicht geht). Die angefragten Konstanten kann man offenbar getrost vergessen.

Jetzt funzt das Auslesen des Sensors, schade ist nur, dass mehr als 9600 Baud nicht möglich sind.

Gruß

PA

Hallo, Spezialisten,

wir wollen einen Sensor mit RS232-Schnittstelle am Konsolen-Port auslesen. Getriggert wird er mit einem Hardware-Signal. Das funktioniert. Die Daten kommen bei meinem Programm nur teilweise oder auch gar nicht an. Der Sensor wurde bisher über eine Umsetzung RS232 -> DeviceNet betrieben (früheres Thema KL6031), daher wissen wir, dass der Sensor auswertbare Daten sendet. Die Umsetzung dauert für schnelle Messanwendungen aber zu lange, deshalb wollen wir es direkt mit der RS232-Schnittstelle versuchen.

An die Schnittstelle am Schaltschrank (DSub 25 polig) werden vom Sensor mit 9600 Baud 15 byte gesendet (das Geschehen wurde mit Schnittstellentester und Oszilloskop geprüft). Am DSub-Stecker, der von außen aufgesteckt wurde, wurde Pin 4 mit 5 und Pin 6 mit 20 gebrückt gemäß Handbuch 82595.

P2: soll konfiguriert werden:
1. Beabsichtigt ist, für P2: X on/off zu deaktivieren mit
stat=SET_PORT_ATR(port_?,atr_xonoff,xf_not_used)
Da die Ports standardmäßig mit XONOFF arbeiten, muss man es deaktivieren. Ich habe versucht, den richtigen Port zu finden, indem ich nachfolgende Abfrage verwendet habe:

atr_value=-1
stat=GET_PORT_ATR(port_2,atr_baud,atr_value)
-- atr_value bleibt -1, egal, ob statt port_2 port_1 oder port_3 angegeben ist
In der Karel-Doku auf S. 138 findet sich

The following STRING values can be used to associate file variables with serial communication
ports on the KAREL controller. Defaults for are:
— ’P2:’ - Debug console connector on the outside of the operator panel

Auf S. 139 kommt
--literal communication port
OPEN FILE file_var4 (’RW’, ’P2:’)

d.h, man kann diesen Port benutzen.

Jetzt fehlt f. das Setzen und Abfragen der Port-Attribute die Zuordnung der phys. Ports zu den vordefinierten Konstanten port_1, port_3, port_4 und port_5. Zufällig habe ich entdeckt, dass der Floppy port_2 zugeordnet ist (s. S. 365). Zu den anderen Konstanten gibt es keine Angaben.
stat=SET_PORT_ATR (port_2, ATR_READAHD, 1) -- sets FLPY: to have a read
-- ahead buffer of 128 bytes.

Weiß jemand, welche Konstante (port_1, port_3, port_4 und port_5) dem phys. Port P2: zugeordnet ist?

Gruß

PA

Hallo, KUKA-Gemeinde,

wir umfahren mit einem KR2180L150, KRC2, SW 4.7, quaderförmige Gebilde unterschiedlicher Höhe. Die Quaderbreite ist immer gleich. Die Quader werden so umfahren, dass der Roboter ein senkrecht stehendes Rechteck mit abgerundeten Ecken abfährt (CIRC-Bewegungen). Der Roboter ist vom Typ FLOOR und führt das Werkzeug waagerecht um diesen Quader herum (Achse 5 ist also in Kanonenstellung). Die Geschwindigkeits- u. Beschleunigungswerte beim Umfahren werden immer gleich vorgegeben. Trotzdem wird ein flacher Quader deutlich langsamer umfahren, als es die Werte vorgeben.

In einigen Fällen (alle paar Tage) kommt es zu der obigen Fehlermeldung. KUKA hat uns 2 Mal empfohlen, den Wert für $curr_mon[5] (max. Effektivstrom in Ampere) zu erhöhen. Selbst eine Erhöhung von 9.3 auf 13.3 ändert nichts. Gibt es noch andere Variable, mit denen eine Besserung erzielt werden könnte? Die Reduzierung der Beschleunigung dürfte nicht das richtige Mittel sein, Die Verwendung von KUKALOAD und damit einhergehende Änderung der Lastdaten hat nix gebracht. Die Motoren sind auch im Dauerbetrieb höchstens handwarm. Wir betreiben den Roboter im Grenzbetrieb, das ist uns bekannt. Die Anlage läuft seit 7 Jahren, der Fehler ist auch schon so lange vorhanden, jetzt wollen wir es aber wissen.

Danke für Infos.

Gruß

PA