Beiträge von HarryH

Hallo zusammen,

danke für alle Hinweise, haben aber noch nicht den erwünschten Erfolg gebracht.

Ich habe die "BRAKETESTREQ()" sowie die An-/Abfahrtroutinen angelegt und geteacht. Der Bremsentest wird vom System angefordert (SIGNAL $BRAKETEST_REQ_INT $OUT[183] ;TRUE= Bremsentest wird angefordert) und fährt auch automatisch dort hin. In der Bremsentestposition bleibt er dann stehen mit der besagten Meldung.

Die Variablen "$AX_SIM_ON" und "$SIMULATED_AXIS" habe ich auch gefunden. Weiß natürlich nicht ob man dort etwas "drehen" darf.

Gruß
HarryH

Hallo zusammen,

ich habe bei einem KR180-2PA V5.6.8 (Palettierer) ohne Zusatzachsen mit SafeRobot V2.2.6 folgende Fehlermeldung:

"Achsen können nicht simuliert werden. Bremsentest wird nicht durchgeführt".

Nach der Fehlermeldung bleibt der Roboter einfach stehen und der Bremsentest wird nicht durchgeführt.
Hat jemand eine Idee woran das liegen könnte?

Gruß HarryH

@ rdizzy, @ Anubis,

"Base_shift.A = 180" geht auch, da ich für die BASE-Verschiebung immer genau 180° habe (gegenüberliegende Ecke der Palette).

Der resultierende A-Wert nach der Doppelpunktoperation wird (wie Anubis schon gesagt hat) ja durch das alte BASE bestimmt.

Danke nochmal für die rege "Anteilnahme"

Gruß HarryH

Vielen Dank für die Antworten,

hat mir sehr weitergeholfen. Habe das jetzt so gelöst:

BASE_Shift = $NULLFRAME
BASE_Shift.x = nPallet[Laenge]
BASE_Shift.y = nPallet[Breite]
BASE_Shift.a = BASE_Shift.a + 180
BASE_DATA_NEU = BASE_DATA_ALT : BASE_Shift

Gruß HarryH

Hallo zusammen,

ich habe einen Palettierroboter KR180-2PA mit KRC2 Steuerung. In der Anlage wird auf 2 Palettierplätzen auf Paletten 1200x800mm palettiert. Für beide Palettierplätze habe an der jeweiligen Palette ein eigenes BASE-Koordinatensystem eingemessen. Der Nullpunkt der BASE liegt an einer Palettenecke. Die X-Y-Ebene liegt auf der Palettenoberseite. Die positive X-Achse zeigt an der Palettenkante in Längsrichtung der Palette, die positive Y-Achse zeigt an der Palettenkante in Querrichtung der Palette und die positive Z-Achse geht senkrecht nach oben. Die BASE kann beliebige X,Y,Z,A-Werte haben. Die B- und C-Komponente sind zu vernachläßigen, da die Palette waagerecht ausgerichtet ist.

Nun zu meiner Fragestellung:
Ich möchte das BASE-Koordinatensystem um 180° drehen, allerdings nicht um den Nullpunkt der BASE sondern um die Palettenmitte gedreht, so dass die BASE auf der diagonal gegenüberliegenden Seite der Palette liegt. Wie kann ich das rechnerisch am Besten lösen?

Gruß HarryH

Hallo Ralle,

es gibt Systemvariablen in denen die von dir gewünschten Anwahlen gespeichert sind. Diese könnte man zyklisch über die SPS.sub z.B. im Handbetrieb T1 und T2 mit festen Werten beschreiben, so dass der Bediener diese nicht ändern kann.

Im folgenden ein Programmcode für die SPS.sub mit welchem die Programmablaufart, der Einricht- und Programm-Override und das Koordinatensystem im Handverfahren fest vorgegeben werden kann. Allerdings weiß ich nicht ob das so funktioniert, weil ich es selber es noch nicht gemacht und ausprobiert habe. Aber es hilft dir vielleicht weiter.

Im Anhang nochmal die Systemvariablen von KUKA. Dort könntest du nochmal gucken was es für die besagten Variablen noch für "Möglichkeiten" gibt. Eine Variabel für "Verfahren mit Statustasten habe ich auf die Schnelle nicht gefunden.

IF ($MODE_OP == #T1) OR ($MODE_OP == #T2)THEN
  $PRO_MODE = #GO     ; Programmablaufart
  $OV_JOG = 10        ; Einricht-Override [%]
  $OV_PRO = 10        ; Programm-Override [%]
  $COSYS = #CAR       ; Koordinatensystem im Handverfahren
ENDIF

Gruß HarryH

Ahhh, is ja ganz einfach. Stand ebend völlig auf dem Schlauch

StrComp():

bStrUngleich==FALSE
  FOR i=1 TO  80
    IF stTextLast[i]<>stText[i] THEN
      bStrUngleich=TRUE
    ENDIF 
  ENDFOR

StrClear():

FOR i=1 TO  80
      stTextLast[i]=" "
    ENDFOR

Gruß HarryH

Hallo zusammen,

ich verwende für die KCP Textausgabe die Stringfunktionen "StrComp()" und "StrClear()". Nun habe ich erstmals einen alten Roboter KRC2 V4.1.5 zu programmieren und stelle fest das der Roboter diese Befehle nicht akzeptiert.

Gibt es vergleichbare Funktionen, oder wie kann ich die beiden oben erwähnten Funktionen anders realisieren? Ich hoffe ihr könnt mir weiterhelfen. Brauche dringend eure Hilfe

Gruß HarryH

Danke PeterDausK,

deine verwendete GSD-Datei scheint für eine KRC1 Steuerung zu sein. Zumindest steht das in der Datei. Auch scheint das keine Siemens Karte CP_5613/14 zu sein(?).

Kann noch jemand zu diesem Thema etwas sagen?

Gruß HarryH

Hallo zusammen,

ich hab es mit einem gebrauchten KR180PA mit KRC2 (V4.1.5) aus dem Jahre 2003(?) zu tun. Der hatte von Anfang an eine Profibus Master/Slave Karte (CP_5613/14) eingebaut, von welcher bisher nur die Master Sektion für die Greiferansteuerung verwendet wurde. Nun soll der Roboter auch an die SPS als Profibus Slave angebunden werden. Beim Vergleichen der "pfbms.ini" von dem gebrauchten Roboter mit (V4.1.5) mit einem aktuellen Roboter aus diesem Jahr (V5.5.x) habe ich Unterschiede festgestellt. Siehe folgende Gegenüberstellung:
Linke Spalte -> pfbms.ini, V4.1.5
Rechte Spalte -> pfbms.ini, V5.5.x

[CP_5613/14]                                       [CP_5613/14]
DEBUG=1                                            DEBUG=1
LOGFILE_PATH=init/profibus.log                     LOGFILE_PATH=log/pfbms.log
ERROR_TEXT=German                                  ERROR_TEXT=German
FORCE_RESET=0                                      FORCE_RESET=0
                                                   OLD_ERROR_DB=0


[MASTER]                                           [MASTER]
MASTER_USED=1                                      MASTER_USED=1
DATABASE_PATH=init/GREIF_VE.LDB                    DATABASE_PATH=init/GREIF_VE.LDB
FIRMWARE_PATH=drivers/FW_5613.bin                  FIRMWARE_PATH_A1=drivers/FW_5613.bin
                                                   FIRMWARE_PATH_A2=drivers/FW5613A2.bin
WATCHDOG_TIME=3                                    WATCHDOG_TIME=3
MAPPING_USED=0                                     MAPPING_USED=0
MAPPING_PATH=init/                                 MAPPING_PATH=init/
;DEACTIVATED_SLAVES=                               ;DEACTIVATED_SLAVES=


[SLAVE]                                            [SLAVE]
MODUL_USED=1                                       MODUL_USED=1
MODUL_ADDRESS=8                                    MODUL_ADDRESS=8
;START_TIME=20                                     ;START_TIME=20
ERROR_ACTION=0                                     ERROR_ACTION=0
STANDBY=1                                          STANDBY=1
SLAVE_TIMEOUT=0                                    SLAVE_TIMEOUT=0
CHECK_CONFIGURATION_DATA=0                         CHECK_CONFIGURATION_DATA=0
ACCEPTABLE_INPUT_LENGTH=244                        ACCEPTABLE_INPUT_LENGTH=244
ACCEPTABLE_OUTPUT_LENGTH=244                       ACCEPTABLE_OUTPUT_LENGTH=244
IO_DATA_BASE=0                                     IO_DATA_BASE=0
CONSISTENCE=0                                      CONSISTENCE=0

Nun meine Fragen:

1. Benötige ich für diesen alten Roboter evl. eine andere/ältere GSD-Datei für die Einbindung des Slave-Sektion in die S7 verglichen mit einem aktuellen Roboter aus diesem Jahr? Ich selber bin seit 2006 dabei KUKA zu programmieren (Ab V5.2.12) . Seit der Zeit verwende ich immer die selbe GSD-Datei um den KUKA einzubinden:
GSD-Datei: S0100008.GSD / KUKA CP5614 Slave

2. Gibt es hier jemanden der auch SPS programmiert und mal nachgucken kann welche GSD-Datei er für einen Roboter mit V4.x verwendet. Und falls diese abweichend ist von der oben beschriebenen, diese mir zukommen lassen kann?

Ich benötige diese Informationen weil ich den Roboter nicht zur Verfügung habe und ich auch nicht zur IBN fahre. So möchte ich das oben Beschriebene im Vorfeld abklären und für meinen IBN Kollegen alles vorbereiten.

Gruß HarryH

Zitat von Loipe

meine vermutung ist:

pHilf fährt er ja im einen fall zweimal hintereinander wenn die zu dicht liegen kann es sein das er den net überschleift wenn die überschleifdistance zu hoch ist

Das ist so nicht richtig. Wenn die Überschleifdistanz größer ist als die Wegstrecke, dann wird die Überschleifdistanz automatisch von der Steuerung reduziert. Und zwar auf die halbe Wegstrecke. Ein Vorlaufstop wird dadurch nicht ausgelöst.

Allerdings gibt es schon den Fall, das der Roboter Punkte nicht verschleifen kann wenn diese zu dicht liegen. Und zu dicht bedeutet im 0.1mm Bereich. Bin mir da aber nicht sicher. Aber in deinem Fall hast du ja min. 50mm Wegstrecke (Offset). Das ist überhaupt kein Problem.

Gruß HarryH

Woran merkt ein Ostfriese das Ebbe ist?

Wenn es beim Rudern staubt!

Hallo zusammen,

die Lizenzanforderung und der Download ist hier noch möglich. Habe heute (Mi.29.12.2010) um 17Uhr noch eine Lizenz bekommen.

http://pro.de/aktion/chip/ultra

1. Formular dort ausfüllen. -> Daraufhin bekommt man eine Bestätigungsmail
2. Den Link in der Bestätigungsmail anklicken -> Man bekommt innerhalb der nächsten Stunde eine Mail mit der Lizenznummer und dem Downloadlink von UltraEditV15.2
3. In der Mail mit der Lizenz gibt es einen Link mit dem man sich vom Newsletter wieder austragen kann.

Viel Erfolg
Gruß HarryH

WolfHenk

Wenn man mit Projekten in UltraEdit arbeitet und ein Projekt öffnet, dann legt UltraEdit eine *.pui-Datei an ("Projekt-name.computer-name.username.pui"). Bei der alten Version die ich hatte war das noch nicht der Fall.
Kennst du eine Möglichkeit dieses Erstellen der Datei zu verhindern? Oder zumindest einen festen "Dummy"-Speicherpfad für diese *.pui-Datei anzulegen?

Gruß HarryH

Das is ja nen Ding. Heute morgen (Mo. 27.12.) hat es noch funktioniert. Habe noch einen Lizenzschlüssel bekommen.
Warscheinlich haben die von Chip am WE nicht gearbeitet, so das die den Download erst heute im laufe des Tages rausgenommen haben.

für den "Fehlalarm"!

Gruß Harry

Hallo Roboterprogrammierer,

im diesjährigen Chip Download Advendskalender 2010 gibt es UltraEdit 15.2 als Vollversion zum runterladen. Man muss sich mit seiner E-Mail registrieren und bekommt den Lizenzschlüssel dann zugesandt.

http://www.chip.de/downloads/U…Vollversion_45252670.html

Gruß HarryH

Hallo liebe Robotergemeinde,

ich wünsche euch allen frohe Weihnachten und einen guten Rutsch ins neue Jahr 2011!

:OLA:

Mit dem "Rutsch" nicht wörtlich nehmen, bei dem Wetter lieber etwas langsamer fahren! :zitter:

Danke nochmal an alle die an diesem Forum mitwirken! Eine sehr große Hilfe!

Gruß HarryH

Anubis

KLAR das ist es, so sollte es gehen! Ich verwende ja schon die Syntax "... pActPos1:{x 0,y -100,z 0,a 0,b 0, c 0}" für Offset im Toolkoordinatensystem. Bin nicht auf die Idee gekommen diese Position erstmal zu speichern und dann die 2. Position daraus abzuleiten. So werde ich das jetzt ändern. Nochmal vielen Dank für die Lösung

Gruß HarryH

Anubis

Genau das ist auch mein Problem. Wie bekomme ich "berechnungstechnisch" die relativen Toolkoordinaten berücksichtigt.

Hallo zusammen,

bei einem KR150-L110 mit KRC2 Steuerung habe folgendes Problem. Ich habe ein Greifwerkzeug mit welchem ich Säcke in unterschiedliche Ablagevorrichtungen lege. Nach dem Ablegen ist immer eine Offsetfahrt von y-100 nach Toolkoordinaten erforderlich. Anschließend wird der Greifer mit einem festen C-Wert =-175 und einem Offset von Z+200 freigefahren. Ich habe das bis jetzt wie folgt gelöst:

$TOOL=TOOL_DATA[1]
$BASE=$WORLD

pActPos1=$POS_ACT
LIN (pActPos1:{x 0,y -100,z 0,a 0,b 0, c 0}) C_DIS

pActPos2=$POS_ACT
pActPos2.c=-175
pActPos2.z=pActPos2.z + 200
LIN pActPos2 C_DIS

Um die Leistung zu verbessern, möchte ich die beiden Punkte verschleifen. Das geht aber nicht da ich den Punkt pActPos2 mit $POS_ACT einlese.

FRAGE: Wie kann ich den zweiten Verfahrpunkt (pActPos2) aus dem ersten Punkt (pActPos1) berechnen, um nicht ein zweites Mal $POS_ACT verwenden zu müssen?

Ich stelle mir das dann so vor...

$TOOL=TOOL_DATA[1]
$BASE=$WORLD

pActPos1=$POS_ACT

LIN (pActPos1:{x 0,y -100,z 0,a 0,b 0, c 0}) C_DIS
pActPos2= --> Hier eine Berechung von pActPos2 bezogen auf pActPos1
pActPos2.c=-175
pActPos2.z=pActPos2.z + 200
LIN pActPos2 C_DIS

Ich hoffe ihr wißt was ich meine. Hat jemand einen Tipp für mich?

Gruß HarryH