Beiträge von fubini

Hallo,

nur zur Info (bezogen auf V8.2 ich vermute aber mal, dass sich die V5.x da nicht grundlegend anders verhält):

VW-Welt:
wenn die Anzahl aller gesetzten aktive Kommandos verriegelnden
Meldungen gleich der Anzahl aller gesetzten aktive Kommandos
verriegelnden Meldungen des Anpassteils + der Anzahl aller von
extern quittierbaren aktive Kommandos verriegelnden Meldungen
ist

+ wenn die Anzahl aller gesetzten aktive Kommandos verriegelnden
PHG Meldungen gleich der Anzahl aller gesetzten aktive Kommandos
verriegelnden PHG-Meldungen des Anpassteils + der Anzahl aller
von extern quittierbaren aktive Kommandos verriegelnden PHG
Meldungen ist

+ wenn die Anzahl aller gesetzten RC_READY verhindernden
Meldungen mit der Anzahl aller RC_READY verhindernden
Meldungen des Anpassteils übereinstimmt

+ Roboter ist justiert

+ keine Busfehler liegen an

=> RC_READY = 1

Erläuterungen:

- Die Meldungen für die Justierung dürfen aktive Kommandos
nicht verriegeln, da sonst nie ein Justieren möglich wäre
- Die Meldungen für IO-Busfehler dürfen aktive Kommandos nicht
verriegeln, da sonst nicht einmal mehr Handverfahren möglich wäre

=> daher müssen diese beiden Fälle hier gesondert behandelt werden

KUKA-Welt:
wenn die Anzahl aller gesetzten aktive Kommandos verriegelnden
Meldungen mit der Anzahl aller gesetzten aktive Kommandos
verriegelnden "Ausnahme-Meldungen" übereinstimmt

+ wenn die Anzahl aller gesetzten aktive Kommandos verriegelnden
PHG Meldungen mit der Anzahl aller gesetzten aktive Kommandos
verriegelnden "Ausnahme-PHG-Meldungen" übereinstimmt

+ wenn die Anzahl aller gesetzten RC_READY verhindernden
Meldungen mit der Anzahl aller RC_READY verhindernden
"Ausnahme-Meldungen" übereinstimmt

+ Roboter ist justiert

+ keine Busfehler liegen an

=> RC_READY = 1

Erläuterungen:

- Die Meldungen für die Justierung dürfen aktive Kommandos
nicht verriegeln, da sonst nie ein Justieren möglich wäre
- Die Meldungen für IO-Busfehler dürfen aktive Kommandos nicht
verriegeln, da sonst nicht einmal mehr Handverfahren möglich wäre

=> daher müssen diese beiden Fälle hier gesondert behandelt werden

Gruß
Fubini

Hallo,

Wie du schon sagst handelt es sich bei der Angabe von 0.001° um eine Angabe die sich auf den Regler in den Antrieben bezieht. Neben dem Regler gibt es aber auch noch den Interpolator in der Steuerung der auf IN_POS_MA/CAR schaut:

$IN_POS_MA/CAR geben in der Steuerung an wann aufgehört wird Sollwerte an die Antriebstechnik zu schicken und auf den nächsten Bewegungssatz zu wechseln. D.h. also falls das Positionierfenster erreicht ist, sagt der Interpolator der Steuerung, dass der Zielpunkt erreicht ist. Das heisst aber noch nicht, dass der Roboter dann schon stehen bleibt. Der Regler ist ja weiterhin aktiv und zieht einen das letzte kleine Stück auf die eigentliche "wahre" Zielposition der Bewegung. Je kleiner das Positionierfenster gewählt wird umso länger bleibt also der Interpolator aktiv und das positionieren dauert länger. Um also insbesondere bei Genauhalt, d.h. nicht überschliffenen Bewegungen, Zeit zu sparen ist es eher günstig ein größeres Positionierfenster zu wählen. Will man aber möglichst exakt positionieren muss man nach Erreichen der Zielposition durch den Interpolator noch etwas warten bis der Regler einen auf die "wahre" Zielposition gezogen hat.

Auf jeden Fall wäre es aber mal einen Versuch Wert das Positionierfenster deiner Problemachse testweise zu verkleinern. Ferner spielt dann auch das Verhalten der Achse bzw. die Parametrierung des Reglers dieser Achse eine Rolle:
Sollte z.B. die Bremse der Problemachse einfallen (siehe $BRK_DEL_EX=200 ms, zu kurz?) bevor der Regler einen auf den "wahren" Zielpunkt der Bewegung gezogen hat könnte ich mir vorstellen, dass es zu dem von dir beschriebenen Verhalten kommt. Auch sollte man nochmal die Reglerparameter in den Maschinendaten anschauen insbesondere die Parameter die die Positionsverstärkung im Regler beschreiben (welche das sind weiss ich jetzt auswendig leider nicht, ich kann aber nächste Woche im Büro mal nachschauen).

Gruß
Fubini

Hallo,

um was für eine SW-Version handelt es sich denn? Ich frage desshalb weil es für Splinebewegungen (SLIN,SCIRC, SPL) ab der V5.6 (vielleicht auch schon V5.5, da bin ich mir aber nicht sicher) einen Modus gibt in dem man jeden Splineblock eine Zeit mitgeben kann in der er ausgeführt werden soll ($TIME_BLOCK-Anweisungen). Die Steuerung skaliert hierbei aber nicht nur die Geschwindigkeit auf die programmierte Verfahrzeit, sondern versucht es auch mit möglichst gleichmässiger Geschwindigkeit.

Gruß
Fubini

Hallo,

ich vermute mal der Roboter steht nicht ganz "gerade" auf der Zusatzachse. Habt ihr mal eine Zusatzachsvermessung durchgeführt und die daraus resultierende Position des Roboters auf der Zusatzachse in die Maschinendaten eingetragen?

Gruß
Fubini

Hallo Tobby,

erstmal keine Panik: Der Roboter ist nicht vergesslich. Nach Programreset ist einfach noch kein Werkzeug aktiv und ohne aktives Werkzeug (und auch aktives Base) kann der Roboter nicht wissen wo er kartesisch steht. Sobald du aber über den ersten kartesisch getachten Punkt fährst muss ja ein Tool (und ein Base) gesetzt sein und die Meldung sollte sofort verschwinden.

Gruß
Fubini

Hallo soma,

die Struktur ist vom Typ CONT:
STRUC CONT INT CVEL,CPTP, REAL CDIS,CORI
...
DECL CONT $APO

Gruß
Fubini

Hallo,

falls du es numerisch machen willst, weiss ich das der Code aus der Robotics Toolbox von Peter Corke korrekt funktioniert:

http://petercorke.com/Robotics_Toolbox.html

Du kannst ja den Quellcode anschauen und das gleiche Verfahren nutzen. Oder du schaust dir gleich die analytische Lösung beim als Beispiel integrierten Puma560 an. Der ist kinemtisch vom Aufbau her identisch zu deinem Roboter.

Gruß
Fubini

Hallo darobbi,

versuch mal telnetk 192.0.1.1 -> ifShow das sollte alle Netwerke inklusive der gewünschten Daten auflisten.

Gruß
Fubini

Hallo,

schau dir mal in der Doku den RESUME Befehl an. Mit dem kannst du sowas machen.

Gruß
Fubini

Hallo,

Zitat

Also ich sehe mit bloßem Auge wirklich keinerlei überschleifen an der Stelle.

setz mal $STOPNOAPROX auf TRUE. und schau ob er

1) in T2 stehen bleibt (in Automatik und extern kommt nur eine Hinweismeldung, falls er nicht stehen bleibt wird auch wenn es nicht so aussieht überschliffen),
2) was für Meldungen kommen und
3) wo im Programm er dann genau steht ($PRO_IP1)

Dann sollte eine genauere Diagnose möglich sein.

Gruß
Fubini

Hallo,

falls nur die V2.8.x in Frage kommt weis ich das nicht, aber allgemein für die KRC1 ist es die V4.1.7.

Gruß
Fubini

Hallo zusammen,

das Ergebnis des : Operators hat immer den Typ der rechten Seite, d.h.

<E6POS> : <POS> = <POS>

Als Beispiel einfach mal unter Anzeige->Variable->Einzeln z.B.
={E6POS: X -1293.20398,Y 785.216187,Z 491.908112,A 89.2432938,B -0.0642487183,C -0.0885750279,S 6,T 19,E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0} : {POS: X 0,Y 0,Z 200,A 0, B 0, C 0}
eingeben. Als Ergebnis erhält man dann
{POS: X -1293.516, Y 784.9960, Z 691.9078, A 89.24329, B -6.424872E-02, C -8.857503E-02}

Damit sind insbesondere nach Ausführung des : die Komponenten S und T im Ergebnis nicht gültig. Zur Ausführungszeit deiner Bewegung bedeutet das es kommt die normale Lückenfüllung zum Einsatz, d.h. fehlende Komponenten werden mit den Werten am Zielpunkt der Vorgängerbewegung aufgefüllt.

Gruß
Fubini

Zitat

Ansonsten gäbe es glaube ich auch noch $SIMULATED_AXIS (oder evtl. $SIMULATED_AXES). Ich glaube das kann man Einfach unter Variablen->Anzeige->Einzeln auf 1 setzen. Dann sind auch alle Achsen simuliert.

Hab gerade noch mal Nachgeschaut. Es heisst $SIMULATED_AXIS und ist ein Bifeld. Also braucht man den Wert 63 für alle Roboterachsen. Hat aber den Vorteil vor $AX_SIM_ON, dass man es eben online ohne ändern der MAschinendaten machen kann.

Hallo [wEm],

Zitat

Also ich hab jetzt die Links von Tilman nicht angeschaut, aber wenn du in der HwInf.ini (C:\KRC\ROBOTER\INIT)einfach
Office = TRUE
setzt, dann wird sich die Mechanik definitiv nicht bewegen, und du musst auch nicht umständlich die Achsen Simulieren.

Stehen dann am realen Roboter nicht ein Haufen Fehler von der Hardware an, die ein verfahren verhindern?

Ansonsten gäbe es glaube ich auch noch $SIMULATED_AXIS (oder evtl. $SIMULATED_AXES). Ich glaube das kann man Einfach unter Variablen->Anzeige->Einzeln auf 1 setzen. Dann sind auch alle Achsen simuliert.

Gruß
Fubini

Hallo,

ich hab es noch nie am realen Roboter mit allen Achsen probiert. $AX_SIM_OM wird aber von KUKA z.B. bei seinen 4-Achspalletieren verwendet um quasi in Software die nicht vorhandene Achse 5 auszublenden, so dass ich davon ausgehe, das da keine Probleme auftauchen.

$AXIS_ACT und $POS_ACT sind noch Werte, die vor der Antriebstechnik abgegriffen werden, so dass sie immer noch wie gewohnt funktionieren sollten.

Gruß
Fubini

Hallo Twister,

du könntest dir mal $AX_SIM_ON (aus R1/MADA/$machine.dat) anschauen. Hier wird sozusagen in der Software die Antriebstechnik des Roboters abgeklemmt. Damit sollte dann alles noch normal funktioniern, nur dass die Motoren nicht angesteuert werden.

Gruß
Fubini

Ja. ist der Radius

Zitat

es gibt insgesamt 8 mal Einträge für $CYLWORKSPACE, welcher davon ist denn relevant?

Normalerweise der erste.

Hallo,

Zitat

ich kann die $machine.dat auch nicht finden... Im Ordner R1 ist sie nicht

Die siehst du nur falls du als Experte angemeldet bist.

Zitat

und wenn ich über den KCP --> Anzeige --> Variable
$CYLWORKSPACE eingebe kommt auch nichts...

Versuch mal $CYLWORKSPACE[1] oder $CYLWORKSPACE[2] oder ... . $CYLWORKSPACE ist ein Feld.

Gruß
Andreas

Hallo casmen,

deiner Programmfehler habe ich zwar nicht gefunden, aber als Anmerkung:

Zustandsmeldungen kannst du sicher nicht von Hand löschen. Das hielte ich auch für sehr gefährlich, da der Meldungstyp Zustandsmeldung ja gerade sagt: bleib solange anstehen bis der Zustand nicht mehr gültig ist. Für Anwendungsfälle in denen ich das nicht so brauche wären eher Quittierungsmeldungen das Mittel der Wahl.

Gruß
Fubini