Beiträge von Hermann

Mathematisch sollte der Roboter die Base exakt drehen.

Die Genauigkeit wird beeinflusst durch:

- Genauigkeit der Tool-Vermessung (das Tool, das zur Base-Vermessung dient)
- Genauigkeit der Base-Vermessung
und nicht zuletzt:
- die absolute Genauigkeit des Roboters (die weitaus schlechter ist als die
Wiederholgenauigkeit)

Hermann

Tja,
wenn ich es noch genau wüsste würde ich es Dir sagen,
kann mich aber an den zweiten Schalter nicht mehr erinnern.
Soweit ich noch weiss war der Schalterhebel für die PIC quasi verlängert,
da der eigentliche Schalter irgendwo ziemlich weit hinten auf
der Huckepack-Platine angebracht war.

Hermann

Hi,
da ist unter einer Abdeckung eines der 'Kuchenbleche' (sprich Einschubkarten) ein kleiner
Schiebeschalter, das ist der Schreibschutzschalter.

Bei ganz alten Steuerungen musste man sogar das Kuchenblech aus dem Rack rausziehen,
um an den Schalter zu gelangen.

Hermann
PS: Ich würde auf jeden Fall vorher mal noch das alte Programm von der PIC sichern!

Hallo Sven,
Das mit dem Doppelpunkt verhält sich etwas anders als das LIN_REL bzw. PTP_REL:

PTP P41_PQ46_2WD:{x -700,y 50,z -250,a 0,b 15,c 0} C_PTP    ;--> Toolkoordinaten
PTP {x -700,y 50,z -250,a 0,b 15,c 0}:P41_PQ46_2WD C_PTP    ;--> Basekoordinaten

Hermann

Au ja, sorry,
hab da wohl nur das letzte Post gelesen,
und die vorherigen wieder vergessen.

Das mit dem externen Programm mach ich seit einiger Zeit genauso, und kann es nur
empfehlen!

Hermann

Ähem,
warum denn so kompliziert?

Warum nicht einfach das vorhandenen SPS.SUB kopieren und weiterentwickeln/ändern ?
Da hat man schon die komplette Struktur, und die Greifertasten (so man Gripper-Tech hat)
funktionieren auch schon.

Hermann

Zitat

Kann ich die P2X Datein auch zurückübersetzen? Schwierig oder?

Nö,
wüsste nicht dass das geht. Selbst wenn, dann fehlen doch die ganzen Symbole, und Kommentare,
ohne die ist die Sache reichlich aussichtslos.

Aber ein Beispiel dazu könnte ich liefern, ist zwar auch nicht mehr ganz Original, aber die Standard-Dinger
sollten doch noch funktionieren. (bitte per Mail melden).
Ein Problem ist, dass es da im Laufe der Zeit einige versch. Versionen gegeben hat, die nicht immer
auf jedem Roboter funktionieren.

Hermann

Hallo,
wenn die Signale an den richtigen Eingängen angeschlossen sind, und das Standard-PIC-Programm auf der Steuerung läuft, dann sollten die Eingänge auch im Roboter ankommen.

Laut meinem alten ausgekramten PIC-Programm sollten die Eingänge 2.4 (also der 12. Anschluss von oben)
und folgenden als Eingang 1 und folgende ankommen.

Die angesprochene Weiterleitung passiert in eben diesem PIC-Programm. Die PIC ist eine eingebaute SPS, die
quasi zwischen der Peripherie (dazu gehört zum Beispiel auch das PHG) und der Robotersteuerung hängt.
Sie verarbeitet die dig. Ein- und Ausgänge und verteilt sie nach entsprechender Zwischenverarbeitung.

Die PIC kann auch mit BAPS programmiert werden. Die entsprechenden Dateien haben die Endung QLS, das
übersetzte Zeug hat die Endung .P2X und kann mit Rops auf die Rho kopiert werden.

Normalerweise sollte das Standard-PIC-Programm schon auf der Steuerung sein, und die Anwendersignale schon
richtig durchreichen. Vermute mal, dass das Gerät gebraucht ist, da könnte es dann schon sein, dass nicht mehr
das 'normale' PIC-Programm drin ist.

Hermann

Anruf bei Fanuc in Neuhausen genügt, Paket kommt postwendend, zumindest war es bei uns so.
Das ist die ganz normale Version, läuft ohne Lizenzschlüssel halt nur 30 Tage.
Man sollte aber keinen allzu alten PC verwenden (besser gesagt einen möglichst neuen Boliden) und mit möglichst
grosser Bildschirmauflösung für die Darstellung des bunten Teachpanels).

Hermann

Hi,
noch vergessen zu sagen: Die Simulationssoftware gibt es als 30 Tage - Testversion

Hermann

Naja,
dann einen Crash-Kurs bei Fanuc und Roboguide zum Offline-Programmieren,
das verhält sich wirklich genau wie der Roboter mit Panel und allem Drum und Dran.

Hermann

Hallo,
max. 50% ack.

Ist alles Geschmackssache, sag ich mal so.

Wir haben einen Kunden (auch in USA), der verbietet Karel-Programmierung. Das hat wohl den Grund, den hier
viele als Vorteil sehen: Karel ist nicht rückübersetzbar, und eigentlich auch nicht wirklich debugfähig.

So, und jetzt progammiert man mal eine auch noch so simple Logik mit ein paar kleinen Vergleichen und
Verzweigungen in TP .
Da zitiere ich einen gewissen W.H.
http://www.roboterforum.de/rob….0.html;msg16714#msg16714

Zitat

...wer goto programmiert, der geht auch alten Omas an die Wäsche...

Aber in TP bleibt mir keine Wahl (was ein Glück wenn da die Oma schon gestorben ist).

Weitere Geschmackssachen (wohlgemerkt nur in TP):
- Keine freie Vergabe von Variablennamen, sondern nur eine begrenzte Anzahl von durchnummerierten Registern
(allerdings mit Kommentar, was ja schon mal nicht ganz daneben ist).
- Das selbe gilt für Positionen.

Apropos mitgeliefertes Handbuch bzw. Doku zu den Robotern, die finde ich im Vergleich zu ABB auch eher seltsam.
Das ist ein Mischmasch aus unzähligen HTML- und PDF-Dokumenten, die man nicht sonderlich gut durchsuchen
kann. Dazu gibt es eine Bedienoberfläche, die teilweise schon mal den halben Bildschirm belegt, so dass für die
eigentliche Info nicht mehr allzu viel Platz übrig bleibt.
Hab mir die in mühevoller Arbeit die einzelnen Abschnitte jeweils in eine PDF-Dateien zusammengefasst, jetzt ist's
einigermassen handhabbar.

Ach ja, dann müsste man noch mal einen Fanuc als Profibus-Master mit modular aufgebauten Slaves konfigurieren.
Keine Doku dazu gefunden, zum Glück ist eine 'Standard-Konfiguration' schon drin, anhand derer man sich dann
rückwärts die Sache zusammenreimen kann, sofern man auf die Idee kommt sich mal in die zugehörigen
GSD-Dateien anzusehen.

So, genug geunkt,
zu Bedienen und Programmieren ist der Fanuc schon recht einfach, und wenn man mit einem anderen Roboter
schon Erfahrung hat, dann reicht Handbuch lesen und selber rumspielen, oder eine eintägige kurze Einweisung
in die Besonderheiten.

Ein Vorteil ist auf jeden Fall mal die Multitasking-Fähigkeit, die man bei ABB immer dazukaufen muss, und bei
der Inbetriebnahme/Änderung der Programme immer etwas hakelig ist.

Zu dem Kurs kann ich nichts sagen, wenn er aber länger als 3 Tage geht, dann halte ich ihn für zu lange.

Für einen 'gelernten ABB-Programmierer' würde ich auf jeden Fall (auch ohne Karel-Programmierung) das Offline-
Tool (OLPCPro oder die High-Tech-3D-Variante ROBOGIUDE) empfehlen, da programmiert sich's einfach etwas
entspannter.

Just my 2 cents.
Hermann

Hi,
wenn ich mich noch recht erinnere kann man bis zu 32 Bit zusammenfassen, dann wird sogar das
höchste Bit als Vorzeichenbit ausgewertet.

Die Lage der Bytes können doch in der IOSYS.INI so verschoben werden, dass sie nacheinander
auf den Eingängen ankommen.
Sowas wie:

INB59=4,2,X1
; normalerweise INB60=4,3,X1
INB60=4,4,X1

Bezweifle aber, dass die Bytes tatsächlich nicht direkt nacheinander erscheinen, tippe da eher auf
einen Fehler in der IOSYS.INI, oder bei der Interpretation der Eingangswerte.

Vergleich geht einfach mit:

if INK_GEB_VORSCH <> INK_GEB_ANTR then
 ; tue dies, lass jenes, oder andersrum
endif

Hermann

Ähh, wie jetzt?
Ablauf immer gleich aber doch anders?

Glaube da solltest Du die Aufgabe noch etwas genauer beschreiben.

Hermann

Zitat

Hm könnte sein, erklärt aber nicht, warum die bei b=90 die Beziehung a=-c gilt...
...
a=-c in meinen Augen unmöglich. Dann wären ja X-Achse und Z-Achse identisch!?!

jetzt hast Du es quasi schon selber erklärt:
bei A 0, B 90, C -90 wird nämlich mit der Drehung um die Y-Achse die X-Achse parallel zur Ausgangslage der Z-Achse gedreht, nur zeigt die X-Achse dann in die engegengesetzte Richtung als die Z-Achse vorher.
Wie schon vorher gesagt es wird immer um die gedrehten Achsen weitergedreht, daher ist die Reihenfolge der
Drehungen entscheidend (zuerst Z dann die gedrehte Y dann die gedrehte X). Wird dann um die X-Achse gedreht
entsteht quasi die selbe Drehung wie um die ALTE Z-Achse, nur in die andere Richtung.

Dass eine Stellung durch unterschiedliche Drehungen dargestellt werden können ist DER entscheidende Nachteil
der Eulerwinkel-Darstellung (daher werden immer öfter Quaternionen verwendet, weiss nicht ob Kuka die evtl.
intern sogar verwendet). Bei der Anzeige der Winkel muss der Programmierer sich halt auf eine Drehung festlegen,
daher kommen die Sprünge in der Anzeige, normalerweise werden da irgendwelche Kriterien wie z.Bsp. Winkel A zwischen -90 und +90 Grad (oder etwas ähnliches) angewandt. Die anderen Winkel ergeben sich dann daraus.
Liegt jetzt der massgebliche Winkel (hier A) genau an einer Grenze, dann können die Winkel halt hin- und
herspringen.

Hermann
PS: Es geht auch ohne Arm brechen, bieg' Dir aus einer Büroklammer ein Dreibein und spiel mal damit rum, da wird
einiges klarer.

Hallo,

Zitat

Versteh ich nicht, in meinen Augen sind die Orientierungen {a 0,b 90,c -90} und {a 90,b90,c 0} nicht gleich...
Bin ich da in einen Spezialfall geraten, bei dem dann noch s bzw. t Wert gesetzt werden müssten???

Hab mir gerade die rechte Hand gebrochen, und komme zu dem Ergebnis, dass die beiden Drehungen identisch
sind.

Zitat

a --> Drehung um Z-Achse
b --> Drehung um Y-Achse
c --> Drehung um X-Achse

sollte eher heissen:
a --> Drehung um Z-Achse
b --> Drehung um die um a gedrehte Y-Achse
c --> Drehung um die um a und b gedrehte X-Achse

Hermann

Hi fubini,
ja mag wohl sein dass ich mich missverständlich ausgedrückt habe, technisch läuft's auf das selbe raus.
Nur helfen wird die korrekte Erklärung dass der Status des Zielpunkts ignoriert wird und der der Ausgangsposition
(könnte ja sein auf der Fahrt auf den Ausgangspunkt wurde der Status auch schon ignoriert) beibehalten
wird, beim ursprünglichen Problem auch nicht.
Da hilft nur andersrum teachen, oder etwa nicht?

Hermann

Hallo,
also s und t alleine helfen da wohl kaum. Beim linear fahren werden die soweit ich weiss eh nicht beachtet. Da ergibt sich die Drehrichtung der Achse 4 automatisch, durch die lineare Bewegung. Versuch mal von Hand per
achsweiser Bewegung nur so ungefähr linear rauszufahren und dabei die Achse 4 in die andere Richtung
zu drehen, ich vermute das wird nicht gelingen.

Das Problem liegt schon vorher: Den Werkzeugwechselpunkt schon anders anfahren, so dass die Achse 4
eben nicht kurz vorm Anschlag steht (also um mindestens 180 Grad verdreht, Achse 5 in die andere Richtung
geknickt und Achse 6 auch um 180 Grad gedreht).
Dazu vorher einen 'richtig' geteachten Punkt per PTP anfahren.

Das kann allerdings in recht viel Arbeit ausarten, je nach Aufbau: zig Punkte neu teachen, evtl.
Schlauchpaket umbauen ...

Hermann

Hi,
ja das sollte wohl dann doch eher $base=$pos_act heissen. Aber unbedingt vorher das Base auf nullframe setzen,
ansonsten passt's wieder nicht. Also:

$base=$nullframe
$base=$pos_act

Die saubere Lösung wäre allerdings mit dem Doppelpunktoperator.

Hermann

Kurze Frage erfordert eigentlich eine lange Antwort,
trotzdem nur eine kurze:

E1-E6 sind die Positionen der externen Achsen, so man welche hat.

s und t stellen die Stellung der Handachsen, den 'Überkopfbereich'
dar, da die meisten Positionen wenn man nur X,Y,Z,A,B,C betrachtet
nicht eindeutig sind ( z.Bsp. Achse 5 auf der anderen Seite der Strecklage
und dafür Achse 4 um 180 Grad gedreht)

Hermann