Beiträge von Drudge

Ja und Nein (=normalerweise sollte man das nicht tun ...)
Wieso brauchst du das?

okay ... ja das könnte wirklich der Fehler sein ... werde ich mal ausprobieren. Danke jedenfalls für die Unterstützung.
gruss Drudge

Danke Roland für die Antwort. So ähnlich hatte ich es probiert:

PROC rMyRoutine (num nStation, VAR signaldi diSignalX)

    TEST nStation
     CASE 1:
       IF diSignalX=1 THEN
         setDO doLampe_1, 1;
       ELSE
         setDO doLampe_1, 0;
       ENDIF
     CASE 2:
       ! nichts
    ENDTEST


  ENDPROC

jedoch beim Aufruf kommt "Syntax Error" sobald ich die Parameter eingebe:

rMyRoutine (1, diSchalterLinks);

Ist es eventuell noch Versionsabhängig? Auf dem Roboter läuft RobotWare V5.14.3071.03

Greez Drudge

Ich weiss nicht. Aber folgendes habe ich mir überlegt:
Ausdehnungskoeffizient von Aluminium (23.1) *23°C / 1'000m = 0.5313 mm Längenausdehnung
Ausdehnungskoeffizient von Stahl (11.0) *23°C / 1'000m = 0.253 mm Längenausdehnung

Gruss Drudge

Hallo miteinander,
ich versuche eine Routine zu erstellen, der ich als Parameter Digitale Signale übergeben kann. Leider kriege ich es nicht hin. Ich ende immer mit einem Syntaxfehler.
In etwa folgendes schwebt mir vor:

PROC rMyRoutine(INOUT signaldi diSchalter, INOUT signaldo doLampe)
 IF diSchalter=1 THEN
  setDO doLampe;
 ENDIF
ENDPROC




PROC main()


 ...
 rMyRoutine (diSchalterlinks, doLampeGruen)
 rMyRoutine (diSchalterrechts, doLampeRot)
 ...


ENDPROC

Leider konnte ich hier im Forum nicht viel hilfreiches finden und in der ABB Doku finde ich lediglich folgenden Hinweis:

Zitat

Data of the data type signalxx must not be defined in the program. However, if
this is in fact done then an error message will be displayed as soon as an instruction
or function that refers to this signal is executed. The data type can, on the other
hand, be used as a parameter when declaring a routine.

Weiss jemand mehr? Kennt jemand den richtigen Syntax oder weiss jemand, dass mein Ansatz mit Sicherheit nicht funktionert?
greez Drudge

Hallo Chris,

wenn ihr mit Experten-KRL Programmierung arbeitet, dann einfach bei den Bearbeitungs-LIN die Geschwindigkeit mit einer Faktorvariablen multiplizieren und diese Variable von extern beschreiben.

falls mit ILF gearbeitet werden muss, könnte folgendes funktionieren:
1. im $config.dat eine eigene Faktor-Variable deklarieren und mit 1 initialisieren.
2. das bas.src modifizieren und die Faktor-Variable einarbeiten.
3. Vorlage.src modifizieren und in allen INIT Falten die Faktorvariable mit 1 initialisieren
4. Im sps.sub die Faktorvariable mit 1 initialisieren (ausserhalb der LOOP)
5. Vor der Bearbeitung den Gruppeneingang lesen und entsprechend die Faktorvariable anpassen
6. Nach der Bearbeitung die Faktorvariable wieder mit 1 initialisieren

gruss Drudge

Hallo Uwe,

1. im $config.dat eine eigene Faktor-Variable deklarieren und mit 1 initialisieren.
2. das bas.src modifizieren und die Faktor-Variable einarbeiten.
3. Vorlage.src modifizieren und in allen INIT Falten die Faktorvariable mit 1 initialisieren
4. Im sps.sub die Faktorvariable mit 1 initialisieren (ausserhalb der LOOP)
5. Vor dem Kleben den Gruppeneingang lesen und entsprechend die Faktorvariable anpassen
6. Nach dem Kleben die Faktorvariable wieder mit 1 initialisieren

gruss Drudge

Hallo Fetzii,
also wegen den 3 Softwarepaketen RSI, RSI XML und Ethernet KRL XML:
- lass dir die Doku's dazu von KUKA schicken, da steht schon sehr viel drin
- so wie ich es im Kopf habe:
>RSI: Interface um direkt in die Robotersteuerung/Bahnplanung Einfluss zu nehmen durch Sensorsignale
>RSI XML: Das Gleiche wie RSI nur dass hier über Ethernet über XML Struckturen Einfluss genommen wird
>Ethernet KRL XML: Option um im KRL über eine Ethernet Schnittstelle via XML Strucktur mit einer externen Steuerung zu kommunizieren (Früher hatte man das über CREAD und CWRITE und der Seriellen Schnittstelle RS232 gemacht)
allerdings bin ich nicht sicher ob und welche Versionen der oben aufgelisteten Softwareoptionen für die KRC3 verfügbar sind und mit dem installierten KSS funktionieren...

gruss Drudge

Hallo Sebel,
ich bin nicht sicher ob ich dein Problem richtig verstehe. Doch funktioniert die Variable $POWER_FAIL für dein Problem nicht?
Gruss Drudge

sollte mit dem Roboter dabei sein ... KSS V8.3 Betriebsanleitung für Systemintegratoren (PDF)

Ich glaube du machst da einige Denk- und Rechenfehler ... probiers mal am Roboter aus.

• Das Resultat vom 2ten Schritt gibt {X 1, Y 2, Z 3, A 9.39, B 0.28, C 26.6}


• A, B, C ist die Orientierung des Toolkoordinatensystems innerhalb des aktiven Basiskoordinatensystems


• rechen Reihenfolge ist Translation (X,Y,Z), Rotation A(Z-Achse), Rotation B(Y-Achse) und am Schluss Rotation C(X-Achse)


• Wenn ich rot:pAct mache dann rotiere ich in der Ausrichtung des Basiskoordinatensystems -> der Nullpunkt wandert sofern in nicht im Nullpunkt vom Basiskoordinatensystem stehe

hör einfach auf mit der Theorie und dem Softwaretool zu spielen ... probiers am Roboter und du siehst was geschieht...

FRAME rot, pAct
rot = $nullframe
rot.B = -30 ; Beispielwert
pAct=$POS_ACT
pAct.x=0
pAct.y=0
pAct.z=0


rot=rot:pAct
rot.x=$POS_ACT.x
rot.y=$POS_ACT.y
rot.z=$POS_ACT.z


LIN rot

Du willst also nur die Toolorientierung ändern, hoffe was ich oben geschrieben habe funktioniert ?

hast du mal

FRAME rot = $nullframe
rot.B = -30 ; Beispielwert


LIN rot:$POS_ACT

probiert?

Hi,
im $config.dat folgendes deklarieren:

ENUM T_Wrkzg_Wahl Werkzeug1, Werkzeug2, Undefiniert
DECL T_Wrkzg_Wahl aktivesWerkzeug = #Undefiniert

und dann vor jedem Werkzeugwechsel

aktivesWerkzeug = #Undefiniert

setzen. Sobald der Werkzeugwechsel erfolgreich abgeschlossen ist, die Variable aktivesWerkzeug gleich dem montierten Werkzeug setzen.
Nach einem Neustart, kannst du dann jeweils in der Variable aktivesWerkzeug rauslesen, was zuletzt montiert wurde ...

GO_Werkzeugcode = aktivesWerkzeug  ;den Integerwert auf einen Signalgruppenausgang schreiben

(Sicherer wären natürlich Codierstecker auf den Werkzeugen ...)

greez

hmm da sind wir wohl nicht überall der selben Meinung
was ich wissen wollte ist: was bedeutet für die Flexibilität in diesem konkreten Fall?

Wenn ich dich richtig verstehe, dann denke ich es gibt das schon was du willst (Allerdings erst ab KSS V8.3):

SLIN Zielpunkt <WITH SysVar1 = Wert1 <, SysVar2 = Wert2, …, >> <C_SPL>
SCIRC Hilfspunkt, Zielpunkt <, CA Kreiswinkel> <WITH SysVar1 = Wert1 <,SysVar2 = Wert2 , … >> <C_SPL>
SPTP Zielpunkt <WITH SysVar1 = Wert1 <, SysVar2 = Wert2 , …>> <C_SPL>

Da kannst du alles in eine Zeile und in Variablen packen ... ganz ohne ILF.

;--- Zwei Beispiele mit Offset Berechnung
   ;MoveJ (OFFSET(XP1,0,0,200),PD100,FD0000,Z100,TOOL01,BASE01)
   SPTP {x 0,y 0,z 200,a 0,b 0,c 0}:XP1 WITH $TOOL=TOOL_DATA[1], $BASE=BASE_DATA[1]


   ;MoveL (TOOLOFFS(XP1,-200,0,0),LD1000,FD0000,FINE,TOOL01,BASE00)
   SLIN XP1:{x -200,y 0,z 0,a 0,b 0,c 0} WITH $TOOL=TOOL_DATA[1], $BASE=$NULLFRAME

Das müsste eigentlich gehen mit Offsets ... wenn ichs richtig im Kopf habe.

greez

mit folgendem Code sollten eigentlich alle Meldungen gelöscht werden. (Details findest du in der Bedienungsanleitung für Meldungsprogrammierung KRC4)

IF NOT Clear_KrlMsg(-99) THEN
  ;FEHLER!!!
ENDIF

LIN $POS_ACT:{X 200, Y 250, Z 300, A 30, B 10, C 5}

Funktioniert das? Kanns gerade nicht ausprobieren und schon länger nicht mehr damit gespielt ...

Hallo MaBo,
das was du vorschlägst, sieht sehr nach ABB aus. Ich komme zwar aus der KUKA Ecke, habe aber nun schon ein paar Programme in RAPID geschrieben... Fazit: ich finde die ABB Art zu Programmieren nicht durchwegs besser und vor allem einengend durch alle diese geschlossenen Funktionen ...
Wenn jedoch ILF-Programmierung und KRL-Programmierung gemischt ist, dann kann es schon ein wenig umständlich werden. Da gebe ich dir recht.
Bezüglich deinem Vorschlag:

• wieso willst du sämtliche Bewegungs und Frameparameter bei jedem Befehl übergeben? Reicht es nicht die Werte nur bei der Initialisierung und bei Änderungen zu laden?


• deine Offsetgeschichte kannst du bei KUKA ganz einfach über den Doppelpunktoperator lösen ...

Kurz ich verstehe nicht ganz genau,
[list type=decimal]

• was im Detail stört dich (in welchen Situationen)

• und wie würdest du es gerne haben?

Hauptgegenargument:

• So ein (1) Roboter kostet mehrere Millionen in der Beschaffung,


• braucht Wartung und Unterhalt,


• braucht trotzallem einen Menschen der ihn Steuert (und Lohn will)


• hat eine Lebensdauer von max 30 Jahren


• dagegen stehen Billiglohnarbeiter von alleine vor der Tür und arbeiten auch 40 Jahre

Tipp: Justiere die selbe Achse in der selben Achskonfiguratione 2-10 mal direkt hinereinander. So kannst du ungefähr erkennen was die "Nullabweichung" ist.
Sobald du grössere Werte misst, bist du dann nicht mehr optimal justiert. die maximalen Werte sind aber auch von der Robotermechanikgrösse und dem Getriebezustand abhängig...

Doch versuchen wir mal den Spass und gehen von einer Kinematikkette mit 6 Achsen mit 0.8 meter Abstand aus. Wir erlauben einen maximalen Fehler von 0.2 mm
-> Katete 0.2mm und Hypothenuse 6*800mm
-> alpha = arcsin(0.2/4800) = 0.002387°
-> das mach pro Achse im Durchschnitt 0.0004° maximale Abweichung (nicht Motorwinkel sondern Achsenwinkel) ...
Bei dieser Berechnung ist vieles nicht berücksichtigt und gewisse Gesetzmässigkeiten vereinfacht (=falsch) angewendet. Ich müsste mal an einem Robi ausprobieren wie sinnvoll oder sinnfrei das obige Resultat ist. Auf jedenfall ist dieser Ansatz kompliziert und unsicher.

Deshalb:
1. Darum den Roboter fahren, bis es wegen der Genauigkeit oder dem Getriebespiel Probleme gibt.
2. Sauber neu justieren und ggf Getriebespiel messen und Getriebeöl kontrollieren.
3. Weiterfahren.
4. Falls Problem bestehen bleibt, betroffene Getriebe wechseln.

Dieses Vorgehen hat sich bewährt.

lg Drudge