Beiträge von HarryH

Warscheinlich ist das Problem von IrrerPolterer schon behoben. Aber bezüglich Tool ungültig und Arbeitsraumüberwachung habe ich folgende Beobachtung gemacht:

Wenn ich eine Arbeitsraumüberwachung aktiv habe und das Programm neu anwähle, erscheint folgende Meldung:

Zustandsmeldung 112: $TOOL ungültig: Keine Arbeitsraumüberwachung möglich

Aber das ist ja auch verständlich, dann es ist nach dem Anwählen noch kein Tool zugewiesen und die Robotersteuerung weiß natürlich nicht, auf welchen TCP sie die Arbeitsraumüberwachung beziehen soll. Erst wenn ein Tool zugewiesen wird, verschwindet die Meldung.

Diese Meldung hat auch beim Kunden schon besorgtes Nachfragen hervorgerufen.

Jo, dat wollt ich noch mal anmerken.
Gruß HarryH

LindePaul für die Antwort!

Habe es gerade selbst in der Werkstatt herausgefunden. Habe alle möglichen Variationen ausprobiert. Byteweise funktionierte dann.

Gruß HarryH

Hallo zusammen,

bei meinem letzten KUKA wurde die Slave- als auch die Master-Sektion vom CP5614 wie folgt verwendet:

[PBMASL]
INw0=4,0 ;$IN[1-16] --> Ansteuerung Werkzeug: Siemens ET200S Compact
OUTw0=4,0 ;$OUT[1-16]

INB2=127,0,x16 ;$IN[17-144] --> Anbindung an SPS
OUT2=127,0,x16 ;$OUT[17-144]

Das läuft einwandfrei!

Nun mein Problem: Statt der Siemens ET200S Compact mit 16 E/A's habe ich jetzt nur die ET200S aus Einzelmodulen --> Kurz gesagt: Ich habe nur noch jeweils 4 (Vier) Ein- und Ausgänge. Was schreibe ich denn in die iosys.ini unter [PBMASL]? Kann ich die Signale auch Bitweise verbinden?

(KRC2, V5.2.14, KR180-2PA)

Gruß HarryH

Danke für eure Antworten!

Stimmt, das "Preparing for Hibernate" war sonst immer zu sehen...

Was mich noch interessieren würde was der Unterschied zwischen Warmstart und Hibernate-Start ist?

Gruß HarryH

Das ist ja toll, die KUKA Hotline hat mir heute was anderes gesagt.
Die sagten mir das default-mäßig die "Warmstart.reg" aktiv ist.

Wat stimmt den jetzt wirklich?

Frage:

Auf der Robotersteuerung gibt es ja die drei *.reg Dateien um das
Hochlaufverhalten der Steuerung festzulegen.
Ich habe mit der ...

coldstart.reg
warmstart.reg
hibernate.reg

experimentiert. Nun weiß ich leider nicht mehr welche *.reg-Datei
standardmäßig bei Auslieferung in der Registrierung eingefügt war.
Kann mir das jemand sagen? Möchte gerne den alten Zustand wieder
herstellen.

Gruß HarryH

@ dingi
Berechnet werden die Ablagepositionen auf der Palette anhand der Produktmaße.

Meine Fragen kommen aus folgendem Hintergrund:
Die Palette die eingemessen wird ist (laut CAD) um 180° gegenüber BASE verdreht. Wenn die Palette nun beim Kunden eingemessen wird, wird die BASE (der Wert "a") nie genau -180.0° haben. Es könnte z.B. a=-179.5 oder a=+179.5. Deswegen meine Frage: Dreht mein Greifer beim Übergang der "Schwelle" BASE.a=+/-180° z.B. links herum statt rechts, also z.B. statt -100° auf +260° Achswinkel Achse6? Oder ist das dem Roboter total wurscht und nimmt immer den kürzesten Weg für Achse 6 (PTP-Bewegung)?
War das nicht so, das wenn ich eine FRAME-Pos anfahre der Roboter immer den kürzesten Weg für seine Achsen nimmt?

Gruß HarryH

Hallo zusammen,

ich habe ne Frage zum manuellen Verdrehen einer BASE. Es geht mir um
das Anpassen des Parameters "a" (Verdrehung um die BASE-Z-Achse).
Konkret habe ich ein BASE welches um 180° gegenüber WORLD verdreht
ist. (Die BASE ist eine Palette/Palettierplatz in einer Palettieranlage mit
KRC2, 5.2.14, KR180-2PA):

BASE_DATA[1]={x 1500.0,y 700.0,z -150.0,a -180.0,b 0.0,c -0.0}

1. Wenn ich eine BASE einmesse, in welchem Bereich kann der Wert "a"
liegen? Ist kleiner "-180" möglich? Oder springt der Wert ab -179.99999
auf +180.0 und umgekehrt?

2. Die berechneten Palettierpositionen werden als FRAME bezogen auf das
BASE angefahren. Frage: Ist der Achswinkel von Achse 6 von einer
Palettierposition bei einem "BASE.a=-179.9" der selbe wie bei einem
"BASE.a=-180.1=179.9"? (Ich meine nicht die sehr geringe Achswinkel
Abweichung Achse 6 die sich aus der Verdrehung der BASE um 0.2°
ergibt). Ich meine, dreht mein Greifer jetzt z.B. links herum statt rechts,
also z.B. statt -100° auf +260° Achswinkel Achse6?

Gruss HarryH

Hallo LindePaul,

es lag an der SPS , nun läufts einwandfrei. das ich dich auf die falsche Fährte geschickt habe und du extra V5.2.14 installieren musstest. für deine Bemühungen!

Es war so:
Der Kollege der die SPS gemacht hat sagte mir, das er den Programmteil zum Anstarten des RobiProgs aus einem lauffähigen Projekt kopiert hat. Da es nicht lief, habe ich das Anstarten auf SPS-Seite blockiert. Allerdings nur den ersten Schritt (Motore EIN). Sobald das Programm gestoppt wurde (CWRITE...,"STOP 1") ), hat die SPS das Programm wieder gestartet.

Nochmal

Gruss HarryH

heute wäre nicht schlecht. Denn die Anlage wird ab morgen nachmittag bei uns in der Firma abgebaut. (Habe ich gerade erfahren). Und geht zu einem Kunden nahe Berlin.

Gruß HarryH

@ LindePaul

Konntest du schon was rausfinden?

Danke, auch schönes Wochenende

LindePaul

STAT.RET1 direkt abfragen funktionierte nicht. Immer Meldung "Objekt nicht gefunden". Habe dann die Deklaration aus der SPS.sub rausgenommen und in die $config.dat eingefügt. Dann wurde STAT.Ret1 beschrieben.

--> Habe die Zeit zwischen den beiden CWRITE Befehlen verlängert (3sek.), um die STAT.Ret1-Werte für beide CWRITEs auch ablesen zu können. Sonst würde es zu schnell durchlaufen.

^{CWRITE($CMD,STAT,MODE,"STOP 1")
WAIT SEC 3
CWRITE($CMD,STAT,MODE,"RESET 1")}

STAT.Ret1- Werte:
CWRITE($CMD,STAT,MODE,"STOP 1") --> #CMD_OK
CWRITE($CMD,STAT,MODE,"RESET 1") --> #CMD_ABORT --> Dies CMD_ABORT klingt logisch, da wie oben schon beschrieben, das Programm durch den ersten CWRITE-Befehl nicht gestoppt wird. Komisch ist nur, das der erste CWRITE-Befehl #CMD_OK zurückliefert.

Habe dann nochmal den zweiten CWRITE-Befehl (...Reset 1) auskommentiert, und wollte nur das Programm stoppen (... Stop 1). --> STAT.Ret1 liefert auch da #CMD_OK aber das Programm wird nicht gestoppt. Jedoch wird eine laufende Roboterbewegung kurz angehalten (siehe oben).

Hast du noch eine Idee? Sollte ich mich nochmal direkt mit dem KUKA-Support in Verbindung setzen?

Roland Keller

Deine Variante zum Rücksetzen des Programms zeigt das selbe Verhalten wie oben beschrieben. Geht leider auch nicht Trotzdem

LindePaul

Danke erstmal für die Doku. Habe folgendes gemacht:
1. In der $config.dat eingefügt: DECL STATE_T Status
2. Habe das Rücksetzen von der SPS angesteuert
3. Variable anzeigen: Status.Ret1 --> Da war keiner
der laut Doku möglichen Werte drin. War nicht
beschrieben.

Ich bin mir aber auch nicht sicher ob ich das richtig
gemacht habe.

@ Roboman
Danke für den Tipp. Werde ich gleich mal ausprobieren.

Gruß HarryH

Hallo zusammen,

ich habe hier einen Palettierer (KR180-2PA, KRC2, V5.2.14) mit dem Softwarepacket "GripperTech". Das Werkzeug hat eine Greiffunktion für die Produkte, sowie für Paletten. Für den Produktgreifer gibt es zwei Ventile für öffnen/schliessen. Das ist kein Thema mit GripperTech.

Für die Ansteuerung der Palettengreifarme (es ist noch eine pneumatische Bremse dran) habe ich zwei 5/3-Wege Impulsventile mit zusammen 4 Spulen. Daraus ergeben sich 4 Zustände des Greifers. Das Problem ist, das nicht ein Ventil für eine Funktion ist, nein, jeder Zustand des Greifers muss aus einer Kombination aller 4 Spulen angesteuert werden (siehe Unten). Wie kann ich jetzt mit GripperTech nur die Funktionen ausfahren/einfahren ansteuern?

Spule
1|2|3|4
|x| |x -> Kolben beide Seiten Druck, Bremse aktiv
|x|x| -> Kolben einfahren, Bremse gelöst
x| | |x -> Kolben ausfahren, Bremse gelöst
x| |x| -> Kolben frei/drucklos, Bremse gelöst

x=angesteuert

Bin für jeden Hinweis dankbar
Gruss HarryH

Hallo LindePaul,

ja es ist eine SPS über Profibus angeschlossen. Die Signale $APPL_RUN und $ROP_STOPPED verwende ich nicht. Zum wieder anstarten des Programms
verwende ich...
Eingänge: $DRIVES_ON, $CONF_MESS, $EXT_START
Ausgänge: $PERI_RDY, $STOPMESS, $PRO_ACT

Um wirklich sicherzugehen das die SPS nicht dazwischen funkt, habe ich das automatische Anstarten auf SPS Seite unterbunden. Die drei oben aufgelisteten Eingänge auf SPS-seite fest auf Null gesetzt. (Zu diesen drei Eingängen in AutExt verwende ich nur noch Fahrfreigabe $MOVE_ENABLE.) -->Selbe Situation: Der Roboter stoppt nur kurz und macht dann der selben Stelle im Programm weiter.

Habe noch folgendes getestet:
- Im "normalen" Automatik Modus lässt sich das Prog. wie gewünscht zurücksetzen (Bei laufendem und bei gestoppten Programm).
- Ist das das Programm im AutExt über den Taster Motore AUS gestoppt, lässt sich das Programm zurücksetzen. --> Daraus folgere ich: Das Programm wird im AutExt über die Zeile "CWRITE($CMD,STAT,MODE,"STOP 1")" nicht gestoppt!? Gibt es eine weitere Möglichkeit das Programm zu stoppen?

Wenn es noch nötig ist: Was ist "STAT.RET1 im RESET-Befehl ..." und wo finde ich das?

Danke für deine Hilfe!
Gruß HarryH

Hallo LindePaul,

Die Softwareversion von meinem jetzigen Roboter ist ist 5.2.14. Bei der
funktionierenden Steuerung ist Version 5.2.12 installiert.

Die Codestelle wird im AutExt durchlaufen. Habe mir eine boolsche Variable
testweise setzen lassen. Habe folgendes festgestellt: Wenn ich das Rücksetzen
während einer Bewegung ausführe, stoppt der Roboter kurz und fährt dann
aber weiter.

In OfficeLite funktioniert das Zurücksetzen problemlos.

Die SPS.sub habe ich mit angehängt.

Gruß HarryH

Hallo zusammen,

habe seit längerem mal wieder ein KUKA (KRC2, KR180-2PA) unter den Fingern. Und schon gibt es wieder Probleme. In der SPS.sub habe ich folgenden Programmcode (Programm stoppen und zurücksetzen):

^{;FOLD USER PLC
;Make your modifications here}

^{; Roboterprogramm stoppen, rücksetzen
IF diRobotReset==FALSE THEN
$FLAG[1]=FALSE
ENDIF
IF (diRobotReset==TRUE) AND ($FLAG[1]==FALSE) THEN
$FLAG[1]=TRUE
CWRITE($CMD,STAT,MODE,"STOP 1") ; Prog stoppen
WAIT SEC 0.5
CWRITE($CMD,STAT,MODE,"RESET 1") ; Prog ruecksetzen
ENDIF}

^{;ENDFOLD (USER PLC)}

Das Problem dabei: Im T1 und T2 wird das Programm zurückgesetzt. Im Automatik Extern nicht! Aber gerade im AutExt benötige ich die Funktion. Was mache ich falsch?
Das merkwürdige ist dabei, das dieser Programmcode bei einem anderen Roboter (auch KRC2, KR180-2PA) richtig funktioniert.

Gruß HarryH

Moin,

habe gerade in der "bas.src" den Befehl "RETURN" entdeckt. Kannte den Befehl vorher nur von ABB.

Ist die Funktion wie bei ABB, also Rücksprung in die aufrufende Routine (eine Ebene höher)?
Kann ich den Befehl ohne weiteres verwenden, obwohl er nicht in der Doku dokumentiert ist?
Weiss jemand was KUKA selbst dazu sagt?

Gruss HarryH

Zitat

Das Resume läßt den Programmzeiger zurückspringen in 'PalletStation' und wird NACH der Zeile: mvBFPalPos(nStationNo) ; Zur Vorposition (nach Sackablegen) - fortgesetzt.

Zitat

@ IrrerPolterer: Warum "...NACH der Zeile: mvBFPalPos(nStationNo)"? Ich denke mal du meinst "...NACH der Zeile: mvPalPos(nStationNo);" !?

Ich verstehe einfach nicht, warum die Routine mvBFPalPos(nStationNo) mit nur dem einen Fahrbefehl nach oben so unterschiedlich ausgeführt wird. Wird die Bewegung vorher mit RESUME abgebrochen ist die Bewegung in mvBFPalPos(nStationNo) deutlich langsamer

Sone Probleme hatte ich bei ABB (S4, S4C, S4C+) nicht!