Beiträge von Boschi

In der Doku steht das stationäre Weltzonen nur in einer POWER ON Eventroutine verwendet werden können, d.h. die Weltzone muss fertig definiert sein, da kann also nichts gerechnet werden während dem Ablauf. In dem Fall hilft Dir CRobT oder sogar nur CPos weiter um den Centerpoint der Weltzone zu bestimmen. Also Greifposition anfahren, dann das im Programm eingefügte CRobT oder CPos einmal ausführen, Daten in Weltzone übernehmen, CRobT oder CPos auskommentieren, Neu starten, fertig.

Ein mögliches Problem bei den Weltzonen für die SPS ist dass sie nur mitbekommt das etwas passiert aber nicht genau was passiert. Legt der Greifer an derselben Stelle auch ab weiß die SPS nicht in welche Richtung die Bauteildaten kopiert werden sollen. Dafür wäre ein Signal 'Bauteil gegriffen' oder 'Bauteil abgelegt' eindeutiger.

"Verstecke" doch die robtargets in einem Offs(robtarget,0,0,0) oder RelTool(...). Damit sind die Positionen zumindest nicht direkt nachteachbar.

Ausserdem hat der Linienführer auch einen optischen Hinweis das diese Position eigentlich nicht nachgeteacht werden soll.

Evtl. kann man zusätzlich das programmieren weiterer Bewegungsbefehle im UAS verhindern (weiss ich jetzt auswendig nicht).

ja, mit ReadCfgData.
z.B. so
ReadCfgData "/MOC/ARM/rob1_1", "upper_joint_bound", reg1;

Ich verwende immer

WHILE TRUE DO
Stop;
ENDWHILE

also ich habe die Erfahrung gemacht das es besser ist das Sytem entscheiden zu lassen wie groß das Datenfeld werden darf. Soll heissen, ich erzeuge den Datensatz den ich möchte (z.B. 1x dnum, 1x string , 2x bool in ein record packen) und erstelle das array am Teachpanel. Wenn's zu groß ist meckert das System.
Erzeugt man das array im Editor wird es zwar geschluckt, man weiß aber nicht was im Hintergrund passiert (kommt es zu heftigen swap Aktionen???). In Robotstudio habe ich obiges Beispiel nur mit 1050 hin bekommen, 1100 ging nicht geschweige denn 2048. An den realen Systemen ist ja z.T. sehr viel weniger 'echter' Speicher drin als in Robotstudio am PC (nur mal so gemutmaßt)

Hallo AndreH,

mit den Workobjekten ist alles in Ordnung. Das z+ so liegt wie Du feststellst liegt daran das ABB nur rechtshändige Koordinatensysteme zulässt (drehe die x-Achse um 90° zur y-Achse dann zeigt z+ dorthin wo sich eine Schraube mit Rechtsgewinde hin bewegen würde).
War das Deine Frage das die wobj's in Ordnung sind? 'Nicht nur' denke ich, deshalb zunächst der Rat Dich mit dem Thema Koordinatensysteme, Pfade spiegeln/kopieren (wie geht's und wann ist was sinnvoll) nochmals intensiv zu beschäftigen. RTFM, man kommt leider selten drum herum.

Für die gespiegelten Nester ist Deine Vorgehensweise (wobj gespiegelt) soweit in Ordnung. Die Pfade sollten dann aber ebenfalls gespiegelt werden (nicht kopiert). Also ein Nest bzw. eine Nesterpaar teachen, via Teachpanel spiegeln, gespiegelte Pfade anpassen (wobj, tool etc.), falls Offs-Bewegungen verwendet wurden müssen die Vorzeichen der Verschiebungswerte auch angepasst werden (normal nur z-Offs), ggf. in neuem Modul ablegen und gespiegelte Pfade nachteachen damit die Konfiguration der robtargets wieder stimmt (die wird nicht gespiegelt).

Hoffe das hilft weiter, viel Spaß und Erfolg beim umsetzen.

Hast Du auch ein System erstellt?
Die Station zeigt Dir nur die Geometrien und Mechaniken, Du kannst auch alles bewegen, aber halt nur in der 'Simulationsumgebung'. Der Tab Offline wird erst gefüllt wenn ein System für die Station erstellt wurde, dann kann auch ein Teachpanel gestartet werden. Außerdem dürfte eine Synchronisierung mit dem VC auch nicht gehn wenn das System fehlt.

Grüße
Boschi

Hallo,

Urmel hat Recht wenn M wirklich der Kreismittelpunkt ist.
Ich hatte das aber so verstanden das die drei Punkte auf dem Kreisbogen liegen.

Betze: Wie liegen denn die drei Punkte?

Grüße

Hallo Betze,

'eine' schnelle Formel wird hier nicht reichen, das Problem stellt sich eher 'nicht trivial' dar.

Wieviel Mathematik bringst Du denn mit?

Mein Ansatz wäre, ein wobj zu bestimmen das im Kreismittelpunkt seinen Ursprung hat und dessen (z.B.) xy-Ebene in Kreisebene liegt. Damit ist die Problematik auf ebene Geometrie reduziert und die n Punkte sind sehr viel leichter berechenbar.

Sind die 3 'Kreispunkte' statisch oder wechseln die mit jedem Bauteil?
Was wir denn überhaupt gemacht auf der Kreisbahn?

Grüße

Hallo Zusammen,

das Thema hat mich dann doch nicht losgelassen und nach ein paar Stunden ging dann doch die Sonne auf (im übertragenen und tatsächlichen Sinn). Hier ist er also, der erste Wurf. Vielleicht n'bisschen old fashioned aber es funzt.

Kurze Zusammenfassung:
- ggf. Perl installieren (ich habe Version 5.8.6)
- ggf. scripte (.pl) mit perl verknüpfen
- script in Ordner ablegen (bei mir ist's F:\bin) und den in den PATH aufnehmen (ansonsten muss das script immer in den Ordner wo das Backup liegt kopiert werden)
- in der Eingabeaufforderung (DOS-Fenster oder Kommandozeile im TotalCommander) script starten und Bildschirmausgabe in Datei umleiten

Beispiel:
Dein IRC5-Backup 'Backup_20100412' liegt in D:\Projekt_xyz\backups.
DOS-Fenster oeffnen, nach D:\Projekt_xyz\backups wechseln dann
"rapid2csv.pl Backup_20100412 > Backup_20100412.csv "
eingeben (ohne "). Mit der Autovervollständigung via TAB-Taste geht das recht flott.

Viel Spaß,
Boschi

Hallo Buschmann,

das ist doch mal ne sinnvolle Aufgabe.
Da ich schon öfters mal perl-scripte erstellt habe um den Quellcode zu ändern oder Infos raus zu ziehen werde ich mich mit dem Thema mal beschäftigen.
Zeitlich möcht ich mich jetzt nicht festlegen aber wenn ich was fertig habe poste ich hier wieder.
Mein Plan wäre ein csv-File zu erstellen das dann recht einfach in Excel geladen werden kann. Noch ne Frage: Welche Datentypen sollens denn sein? Für nen ersten Wurf sollte num, bool und string ausreichen, oder?

Gruß,
Boschi