Beiträge von Drudge

@ Roland56

@ bedro
Ich weiss immernoch nicht, was du genau machen musst. Hast du einen sieben achsigen, nuklearangetriebenen Super-Kran, den du steuern willst? Steuerst du ihn über Seilzüge oder mit reiner Telepatie?
Was ich sagen will: Wenn wir nichts wissen, können wir nicht weiterhelfen.

Ja ich weiss, dass du PTP fahren willst. Aber das ist so ziemlich alles was ich weiss. (Übrigens kann man auch mit dem Fahrrad PTP fahren, einfach zu implementieren über einen biomechanischen Antrieb und einer elektrochemischen Steuerung.)

Also bitte gib uns einbisschen mehr Info's.

lg simeonw

Zitat

Also er soll die programmzeilen nuch bei den bauteilen

nuch = auch?
nuch = nur?
nuch = nicht?
Wenn ich den Rest des Posts betrachte, vermute ich mal, dass der erste Abschnitt folgendes bedeutet:
"Also er soll die Programmzeilen bei den Bauteilen V_TYP_215_ENT_LI und V_TYP_215_ENT_RE nicht abarbeiten."

Zitat

mit dem befehle
...
macht er das klaube ich
so wie du geschriben hast .
Weil die
die bauteile V_TYP_245_ENT_LI und V_TYP_245_ENT_RE
bauchen nicht auf die bürststadion

Alles anzeigen

auch damit habe ich einwenig Mühe. (Ich hoffe mal deine Muttersprache ist nicht deutsch. ) Ich verstehe den Abschnitt folgendermassen:
"Mit dem Befehl, so wie du ihn geschrieben hast, ... macht er das auch. Denn die Bauteile V_TYP_245_ENT_LI und V_TYP_245_ENT_RE müssen nicht auf die Bürststation."

Wenn ich dich also richtig verstanden habe, dann kann ich dich bestätigen: Ja mit meinem pseudo-code werden die Bewegungen innerhalb des IF Blocks und die WAIR FOR Anweisung nicht durchgeführt, wenn das momentane Bauteil V_TYP_245_ENT_LI oder V_TYP_245_ENT_RE ist.

du könntest die gerade zum Zielpunkt in kleinere Stücke aufteilen und dann wieder PTP C_PTP fahren. Dadurch würde das "Ausschlagen" des Roboters bei der Bewegung verringert. (je kleinere Teilabschnitte desto ähnlicher einer LIN Bewegung, mal abgesehen von den Geschwindigkeiten etc.)

oder da es vorher vom Platz her gesehen auch mit PTP ging, kannst du es mit dem $ORI_TYPE = #JOINT versuchen.

hmm ich komme nicht wirklich draus was du machen willst. Doch hier der Pseudocode für das was ich vermute:

ENUM Bauteil_TYP V_TYP_245_ENT_LI, V_TYP_245_ENT_RE, ...
DECL Bauteil_TYP actBauteil


.
.   ;versch. Code
.


SWITCH PGNO
 CASE 1
  actBauteil = #V_TYP_245_ENT_LI
 CASE 2
  actBauteil = #V_TYP_245_ENT_RE
 CASE 3
  ;usw
ENDSWITCH


.
.   ;versch. Code
.


IF (actBauteil<>#V_TYP_245_ENT_LI) AND (actBauteil<>#V_TYP_245_ENT_RE) THEN
;FOLD PTP Z_KIPP_2 CONT Vel= 100 % PDAT1 Tool[3]:Entladegreifer Base[6]:Reibschweissmaschine;%{PE}%R 5.2.271,%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:Z_KIPP_2, 3:C_PTP, 5:100, 7:PDAT1
$BWDSTART = FALSE
PDAT_ACT=PPDAT1
FDAT_ACT=FZ_KIPP_2
BAS(#PTP_PARAMS,100)
PTP XZ_KIPP_2 C_PTP
;ENDFOLD
;FOLD LIN Z_KIPP  Vel= 1 m/s PDAT1 Tool[3]:Entladegreifer Base[6]:Reibschweissmaschine;%{PE}%R 5.2.271,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:Z_KIPP, 3:, 5:1, 7:PDAT1
$BWDSTART = FALSE
LDAT_ACT=LPDAT1
FDAT_ACT=FZ_KIPP
BAS(#CP_PARAMS,1)
LIN XZ_KIPP
;ENDFOLD
;FOLD LIN Z_KIPP_3 CONT Vel= 1 m/s PDAT1 Tool[3]:Entladegreifer Base[6]:Reibschweissmaschine;%{PE}%R 5.2.271,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:Z_KIPP_3, 3:C_DIS, 5:1, 7:PDAT1
$BWDSTART = FALSE
LDAT_ACT=LPDAT1
FDAT_ACT=FZ_KIPP_3
BAS(#CP_PARAMS,1)
LIN XZ_KIPP_3 C_DIS
;ENDFOLD


;FOLD WAIT FOR ( IN 8 'buerste frei' );%{PE}%R 5.2.271,%MKUKATPBASIS,%CEXT_WAIT_FOR,%VEXT_WAIT_FOR,%P 2:, 4:, 5:$IN, 6:8, 7:buerste frei, 9:
WAIT FOR  ( $IN[8] )
;ENDFOLD
ENDIF


.
.   ;restl. Code
.

Lieber Badr so sehr ich mich auch bemühe, ich finde keine einzige Frage in deinem Post. Dazu kommt noch, dass er praktisch nur aus Satzfragmentenbesteht. Dadurch ist es ziemlich schwierig den eigentlichen Sinn des Abschnitts zu erraten.

Kannst du uns bitte die Ausgangslage, das Problem und die Konkrete Frage formulieren? Das hätte zwei Effekte:
1. Durch das Überlegen der Problemstellung wird dir klar welches die konkreten Probleme sind. (Falls das nicht schon geschehen ist.)
2. Wir können dein Problem verstehen und können dir weiterhelfen (was wir sehr gerne tun).

Ich kenne leider die EPSON zu wenig, doch soviel ich erlebt habe sind die KUKA scara's sehr zuverlässig. Da ihr schon so auf KUKA eingelaufen seit, denke ich nicht dass es sich für euch nicht lohnt EPSON einzusetzten. Zum einen ist es sehr praktisch einen einzigen Ansprechpartner für alle Roboterprobleme zu haben, zum anderen spart ihr euch die Zeit zum "Anfreunden" mit den neuen Robotern. Wenn die KUKA Scara's die nötigen Anforderungen erfüllen, dann würde ich an eurer Stelle nicht lange überlegen...

hmm nach meiner Erfahrung, muss ein KUKA Scara sehr selten bis nie neu justiert werden. Nach folgenden Ereignissen muss er aber neu justiert werden:
- Austausch eines Motors
- Tausch von Zahnriemen
- Wechsel eines Getriebes
- Bei einer Kollision schneller als Handverfahrgeschwindigkeit (empfohlen)
Die Justage ist ein bisschen komplizierter als bei den Standardrobotern. Es sind folgende Schritte zu tun:
1. Wenn die Robotersteuerung oder der Roboter ausgetauscht wurde: MAMES Werte in die Robotersteuerung eintragen.
MAMES-Werte sind roboterspezifische Referenzwerte. Wenn der Roboter seine Justageposition erreicht hat, kann er aus dem MAMES-Wert für diese Achse seine Position in Bezug zur Nullposition erkennen.
2. Die zu justierenden Achsen in Vorjustagestellung verfahren.
3. Referenzpositionsschrauben eindrehen
4. Achsen justieren

Das exakte Vorgehen ist in der Betriebsanleitung mit Fotos dokumentiert.

Wenn ich das so mache, kriege ich keine Fehlermeldung:

DEF stoer_20( )
    DECL MSG_T EMPTY_MSG
 
    EMPTY_MSG={MSG_T:VALID FALSE,RELEASE FALSE,TYP #NOTIFY,MODUL[]" ",KEY[]" ",PARAM_TYP #VALUE,PARAM[]" ",DLG_FORMAT[]" ",ANSWER 0}
    $MSG_T=EMPTY_MSG
    $MSG_T.MODUL[] = "USER"
    $MSG_T.KEY[] = "Pruefen ob Kasten Einpacker vorhanden"
    $MSG_T.PARAM_TYP = #VALUE
    $MSG_T.TYP = #QUIT


;--------- Quittmeldung, Roboter setzt fort, wenn Bediener Quittiert ---------------


    $MSG_T.VALID=TRUE
    WAIT SEC 0.2
    WHILE $MSG_T.VALID
        WAIT SEC 0.05
    ENDWHILE




    ;-- Infomeldung --
    ;$MSG_T.VALID=TRUE
    ;WAIT SEC 0.2
    ;$MSG_T.RELEASE=TRUE
END

ich komme zwar nicht ganz draus was exakt das Problem ist, doch zum Punkte umrechnen kann man den Externen Editor verwenden.

Oder das einfachste ist jeweils, das Base nachzuteachen, zu dem die Punkte relativ sind. Dadurch werden alle Punkte auf einen Schlag korrigiert.

hmm ja aber ich denk mal, dass er da gemeint hat, wie der mit ENUM erstellte Datentyp heisst.

Ich habe keine Ahnung was für ein Datentyp das sein könnte. Ich könnte mir allerdings auch vorstellen, dass die ganze Zeile

LIN_REL {x 100.0} #TOOL

als ein Befehl interpretiert wird und nicht als Funktion/Unterprogramm mit Parameter. In dem Fall würde der Befehl geparsed werden und es müsste gar nicht unbedingt einen entsprechenden Datentyp haben. Oder weiss jemand den Datentyp von C_DIS etc.?
Da der Parameter #TOOL und #BASE nur festlegt, in welchem Koordinatensystem bewegt werden soll, kann das auch anders gelöst werden. Wenn du das Bezugskoordinatensystem automatisch wechseln willst, kannst du das auch so ähnlich machen:

IF #TOOL THEN
   WAIT SEC 0.0
   LIN $POS_ACT:{X 50.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0}
ENDIF
IF #BASE THEN
   WAIT SEC 0.0
   LIN {X 50.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0}:$POS_ACT
ENDIF

Dieser Code ist aber nur das Selbe wie LIN_REL {} #BASE oder LIN_REL {} #TOOL solange nicht um A, B oder C gedreht wird. Denn LIN_REL {} #BASE dreht zwar nach der Baserichtung jedoch um den TCP statt das Base. Mit dem obigen Code wird, um das aktive Base (X, Y oder Z-Achse) gedreht.
Wenn auch die Winkel gedreht werden sollen, dann ist es ein wenig komplizierter:

;LIN_REL {x 50.0, C 22.5} #TOOL
WAIT SEC 0.0
LIN $POS_ACT:{X 50.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 22.5}


;LIN_REL {x 50.0, C 22.5} #BASE
WAIT SEC 0.0
bkpBase = $BASE
bkpPos = $POS_ACT
bkpPos = {X 50.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0}:bkpPos
$BASE.X = bkpPos.X
$BASE.Y = bkpPos.Y
$BASE.Z = bkpPos.Z
bkpPos.X = 0.0
bkpPos.Y = 0.0
bkpPos.Z = 0.0
LIN {X 0.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 22.5}:bkpPos
$BASE = bkpBase

Konfiguration -> Statustasten -> ein- / ausschalten der einzelnen Technologie Tasten

hehe man weiss ja nie aber ich dachte da vorallem an die zusatzlasten

Hier noch eine Liste von Dingen, die für Zyklusoptimierung gemacht werden sollten. BEVOR an den Maschinendaten herumgeschraubt wird. (Nur für die, die es noch nicht wissen. )

1. Korrekte Maschinendaten verwenden. Die wirklich vorhandenen Lastdaten eintragen. (Auch Zusatzlasten auf z.B. A3 richtig eingeben.) Wenn keine Last vorhanden ist, eine Last von 0 eingeben und nicht -1 stehen lassen.
2. Sicherstellen dass die Lastdaten auch geladen werden. Es wird oft vergessen die Lastdaten zu laden, wenn nicht mit den INLINE Formularen gearbeitet wird. ($TOOL = TOOL_DATA[1] lädt die Lastdaten nicht!)
3. Immer PTP verwenden, wenn LIN oder CIRC nicht unbedingt nötig. Dadurch bewegt sich der Roboter viel schneller von A nach B und Umorientierungen sind viel schneller. Eventuell müssen halt mehrere aufeinander folgende PTP Befehle an Stelle einer einzelnen LIN bewegung verwendet werden um Crashes zu verhinden. Doch sehr oft bringt das viel für die Taktzeit.
4. Wo immer möglich grosszügig überschleiffen! Verwende Trigger, Interrupts PULSE für I/O's oder mach solche Dinge da wo der Roboter sowieso stillstehen muss.

Also kurz:
- sicherstellen dass die korrekten Dynamikdaten geladen sind
- so programmieren dass der roboter keinen Genauhalt/Vorlaufstop zwischen pick und place hat.
- so bewegen, dass der Roboter möglichst nie linear fährt.

zu 1.

Welche "einfache Ordnerfreigabe" hast du verwendet? (ev. Screenshot) Denn es gibt eine einfache Ordnerfreigabe im Windows, die ich auf einer KRC nicht verwenden würde.

auch zu 3.

Was Thadäus andeutete, steht so in der Doku:

Zitat

Zum Zeitpunkt der RESUME--Anweisung darf der Vorlaufzeiger nicht in der Ebene stehen,
in der der Interrupt deklariert wurde, sondern mindestens eine Ebene tiefer.

Deshalb auch der Hinweis von Robotnik. Durch das

WAIT SEC 0.0

am Ende des Unterprogramms, indem der Interrupt ausgelöst werden sollte, wird verhindert, dass der Vorlaufzeiger die Unterprogrammebene zu früh verlässt.

Ja du könntest etwas basteln mit sps.sub und cycflags

hmm ja du verwendest da eine SPS, aber 1000 Dinge musst du nicht verdrahten. Es reicht ein Bus-Kabel von der SPS zur Robotersteuerung. (z.B. DeviceNet oder Profibus)
Dann kannst du in der Konfiguration die einzelnen Ein- und Ausgänge "virtuell verdrahten"/mappen und diese dann zu Gruppen zusammenfassen. Oder wenn du spezielle Variablentypen brauchst die Bits selber zusammenkleben.

INTERRUPT DECL 17 WHEN $FLAG[1]==TRUE DO Test_var1=TRUE

Ist nicht zulässig, da als Reaktion auf einen ausgelösten Interrupt eine Interruptroutine verwendet werden muss.

INTERRUPT DECL 17 WHEN $FLAG[1]==TRUE DO IR_FLAG1(Test_var1)
.
.
.
END


DEF IR_FLAG1(Test_var1:OUT)
   BOOL Test_var1


   Test_var1 = TRUE
END

Ist auch nicht zulässig, da einer Interruptroutine keine Laufzeitvariablen übergeben werden können. (Test_var1 müsste also eine globale Variable sein.)

DEF test1 ( )


INI


BOOL Test_var1


INTERRUPT DECL 17 WHEN $FLAG[1]==TRUE DO Test_var1=TRUE 


.
.
.

Das würde ich sowieso nicht so kompliziert mit einem Interrupt machen. Sondern einfach mit einem $CYCFLAG:

DEF test1 ()


INI


$CYCFLAG[irgendeineNr] = FALSE
$CYCFLAG[irgendeineNr] = $FLAG[1] OR $CYCFLAG[irgendeineNr]


.
.
.

Dann heisst deine verwendete Variable einfach nicht Test_var1 sondern $CYCFLAG[irgendeineNr].

Das geht natürlich nur, wenn du nicht auf die einmalige Flankentriggerung angewiesen bist. Sonst müsste das noch ein bischen komplizierter gemacht werden oder aber eine Test_var1 als eine globale Variable deklariert werden.

Automatik extern:
- Anstehende Fehler quittieren (ausser Sollmoment fehler oder Änliches)
- Roboter starten und stoppen mit einer SPS (Antriebe ein, Programm starten, Fahrfreigabe wegnehmen, etc.)
- Befehle an Roboter geben in Form einer einzelnen Integervariablen (Kann durch beliebige durch den Bus begrenzte Anzahl Parameter erweitert werden. Muss jedoch selber gemacht werden.)

CREAD und CWRITE:
- habe ich schon ein paar Dinge gelesen, hatte bis jetzt aber noch keine Gelegenheit damit zu spielen. Deshalb weiss ich nicht genau was da geht. Aber ich verstehe es in etwa so, wie du geschrieben hast: Es ist ein Datenkanal (über Serielle SChnittstelle, den man aber selber parsen muss)

OPC
- kenne ich zu wenig, habs nur einmal in sehr kleinem Rahmen verwendet.

Labview
- kenne ich noch weniger

hmm ich denke mal das mit dem Interrupt ist ziemlich schnell und sauber.
du könntest es auch mit dem $MOVE_ENABLE verknüpfen wobei du aber schauen musst, dass im handbetrieb trotzdem gefahren werden kann...
es könnte natürlich auch der bedienerschutz oder notauskreis manipuliert werden ... (wobei das wohl eher eine schlechte Idee ist)

du musst sowieso darauf achten, dass du noch etwas knauschzone hast nach dem der Sensor angibt, denn der Roboter wird in jedem Fall noch eine gewisse nachlaufstrecke haben.

mal ne generelle Frage:
Hast du irgendwelche Treiber, Softwarepakete oder ähnliches für die Karte auf dem Windows installiert?