Beiträge von Bocmok

Aus meiner Erfahrung (default von ABB ), wenn du PZ aus einer Routine in eine andere mittels "PZ auf Routine" machst, dann werden alle Zusatzachsen deaktiviert.

[0,9E+09,45,9E+09,9E+09,9E+09]
hier habe ich gemeint, dass bei dir die 1. zus. Achse = 0; die 2. zus. Achse = 9E+09 (undefiniert), die 3. zus. Achse = 45;
als M8 würde man wahrscheinlich auf die 2. zus. Achse denken, die den Wert von 9E+09 hat (undefiniert).

Ich sehe nicht, dass bei dir die M8 deaktiviert wird... Habe ich das übersehen?
Wenn die Achse aktiviert ist und bekommt ein Target mit [9E+09], dann fährt die nicht etwa "etwas" was ihr selber gefällt?

Und noch etwas, ist die Zuordnung der Achsen so gewollt (nicht etwa, dass es ein Tippfehler ist)?:
[0,9E+09,45,9E+09,9E+09,9E+09]
M7, M8, ...
M7 = 0
M8 = 9E+09

in MAIN wird die M8 aktiviert, was dann in Routine "auswahl;" passiert, sieht man hier nicht.

Komisch, wenn externe Achse deaktiviert wird, dann kommt normalerweise die Meldung, dass der Punkt nicht erreichbar ist, weil eine Achse deaktiviert ist. Oder?
Es kann sein, dass in MAIN extra Befehle für die Aktivierung der Achse gibt und deswegen wird die auf 68,7° gedreht, Punkt mit einem Wert für ex.Achse - so wie mio1777 geschrieben hat. Und da sind normalerweise die Koordinaten von START-Position für alle Achsen.

Hallo,

kann es sein, dass es Ultra Edit (Macro) war?

Der Batteriepack wird bei uns ca. alle 3-5 Jahre ausgetauscht, wird leer...
Unserer Elektriker meinte, dass es zu oft sei... Er hat einen Batteriepack im Robotersockel ausgetauscht, zerlegt und meint, dass drin einer Entladungsmechanismus verbaut ist...
Kann das jemand bestätigen?

Hallo FlashbackXXL,
mit Offline Editor meinte ich etwas anderes als Notepad ++... Obwohl, mit z.B. C++ Kenntnissen kann man ein kleines Programmchen schreiben und alle Z Werte suchen und um 70 ändern. Bei so einer Änderung wird wahrscheinlich die alte Konfiguration des Roboters noch passen. ABER, keine 100% Garantie.
Kinderleicht wäre es, so wie Michael sagte, z.B. mit FAMOS. Schau bei Youtube wie das funktioniert. Oder frage Michael, ob er für dich das als Werbungsgeschenk macht. Vlt. kannst Du damit deinen Chef überzeugen eine FAMOS-Lizenz zu kaufen.

Grüß

Mit einem OffLineEditor schon versucht? Module importieren, in Weltkoordinaten alle Punkte um 70mm verschieben, Module exportieren.?

Übrigens, wenn man ein OLP verwendet, dann kann es auch daran liegen:
wenn man im alten OLP Projekt die WobJ Werte von neuer Anlage nicht eingibt und benutzt nur von alter Anlage, dann kriegt man automatisch ein verschobenes Programm (Diff. zw. WobJ-alt und WobJ-neu).

Elbunde, es wäre auch interessant zu wissen, wo der Fehler war und wie es beseitigt wurde. Melde dich.

Hallo Elbunde,

ich würde sagen - ja.

Wenn du Wobj mit 3 Punkten gemessen hast und diese in einer Ebene liegen, z.B. bei Z=100mm, und zw. den ein kleiner Abstand ist, z.B. 50cm, dann macht der Winkelfehler mit zunehmendem Abstand in Z-Richtung immer größere Verschiebung. Als Abhilfe wäre ev. Wobj so vermessen, dass die Messpunkten von einander wesentlich größerer Abstand haben als deine Programmpunkten vom Wobj-Zentrum.
Oder ist es möglich die Winkelwerten von Wobj in Steuerung auf 0° (wenn es natürlich passt) zu ändern? ich glaube schon.

Grüß Bocmok

Hallo capo68,

ich würde auch, wie hier schon geschrieben ist:
Referenzpunkt mit Messwerkzeug(Spitze) kontrollieren - ob Robi und Werkzeughalterung OK sind,
Nullposition checken - ob, Umdrehungszähler OK ist,
andere Werkzeug einsetzen - ob Werkzeug gebogen wurde,

und noch dazu:
Werkobjekt mit Messwerkzeug kontrollieren - ob Robi oder Werkstückhalter verschoben wurde,
und noch Werkzeughalterung an A6 kontrollieren, vlt. hat die Spiel/wurde verbogen.

Grüß
Bocmok

Hallo

Ich habe eine Frage bzgl. OLP und zwar:
gibt es eine OLP SW, die erlaubt/zulässt die Programme mit einem Script zu erstellen? Die Erstellung von Programmen läuft bei uns (mit FAMOS) nach gleichem Prinzip, z.B.: man nimmt ein CAD Modell, wählt an dem die kürzeren, parallelen Seiten, erzeugt an den Bahne, segmentiert die mit einem bestimmten Raster, verbindet die per Segmentierung erzeugten Punkten, fügt je nach der Rastergröße die passende Geschwindigkeit für Robi. Und die Frage ist, ob man einen großen Teil davon per Script automatisieren kann?

Grüß Bocmok

Hallo Nico,

versuch mal bei wlw.de, da findest du jede Menge davon.
Oder bei einem Hersteller der Roboterschweißzellen bzw. Schweißgeräten/-Lösungen für Robi wie z.B. Fronius. Da kriegst du Info über die Betreiber von solchen Anlagen.

MfG Bocmok

Hallo katler,

aus meiner Mathe Kenntnisse :

aus der Definition vom Normalverktor ist es so, dass der Vektor zu der Fläche immer 90° hat, (zwei weiteren Werten =0°), d.h. wenn die Fläche in der Mitte der kart. Koordinatensystem liegt, hast du 3x0°. Wird die Fläche verdreht/verschoben, dann ist der Normalvektor immer noch zu der Fläche mit 1x90° und 2x0°, aber zum kart. Koordinatensystem gibt es dann anderen, als 3x0° Werten + Verschiebung in x,y,z.
In deinem letzten Beispiel sind diese Werte für diese Verschiebung in mm/Verdrehung in ° bezogen auf ein System.
Ich glaube, es ähnelt sich zu OFrame oder UFrame in RAPID. Diese Werte sind dafür da, um nur vorhandenes Programm räumlich anzupassen, oder?

Ich hoffe, das kann dir helfen.

Danke für den Tip Torsten.
Ich erfrische zuerst meine FAMOS-Version und dann mal sehen, ob es hilft.

Hallo Torsten,

ich habe zuerst deine Theorie getestet. Leider ist es bei mir nicht der Fall.
Ich habe ein kleines Programm mit Bogen und VelSet-Änderungen (vor und danach) erstellt und importiert und exportiert (aber ohne ABB Robotstudio online einzusetzen). Immer (ca.20 Varianten mit hin/zurück) gab es keine Änderung in FAMOS Quellcode.

Bei uns entsteht dieser Fehler auch nicht immer und auch nicht hinter allen Bogenbewegungen. Hmm ich bin ratlos… Noch irgendwelche Ideen???

Zu Famos support: Michael ist einer davon!

Und unseren Chefs sind dagegen, dass einer aus dem Produktionsbereich einen direkten Kontakt nach Außen hat… Deswegen auch keine Schulung über FAMOS usw. Es gibt nur ein Man der das machen darf und er sagt etwa so: ja ich ruf mal die an…. Und wir warten und warten…

Hallo Michael,

VelSet ist bei uns deswegen so beliebt, weil es mit % Zahlen leichter und schneller gewünschtes Ziel (in der Entwicklungsphase) zu erreichen ist. Bei uns sind die Bauteile unsymmetrisch und die Abstände zwischen den Bahnen dann auch. Dies kompensieren wir mit der Geschwindigkeitsänderungen: ist der Abstand um ca. 10% größer geworden, wird die Geschwindigkeit um 10% reduziert.

Zitat

Dann rufst Du VelSet IM Kreis auf. Der Startpunkt, der vor der MoveC-Anweisung angefahren wird, ist ja schon Bestandteil des Kreises.

Ist das ein Problem für FAMOS oder ABB? Eigentlich wird zuerst VelSet gelesen und erst dann MoveC, d.h. zuerst die Geschwindigkeitsanpassung und dann „fahren wir mal Kreis…“ oder?

Zum Import setzen wir nur die Option "nur Positionen und Orientierungen aktualisieren" ein! Wir haben auch schnell rausgefunden, dass man dabei keinen Punkte löschen oder einfügen darf, sonst bekommt man nur Zahlensalat….

Zitat

Und noch eine Anmerkung: wenn Du nicht unbedingt die Robtargets als "PERS" brauchst, weil Du z. B. noch eine Berechnung darauf anwenden willst, solltest Du den Output auf "CONST" umstellen im Konfigurationsdialog. Die Anzahl der PERS im ABB-System ist begrenzt.

Oops das habe ich nicht gewusst. Auf welche Zahl ist „PERS“ begrenzt? Wir haben im Programmen bis zu 3000 – 4000 Points…

Grüß und schönes WE
Bocmok

Hallo Michael,

ich freue mich dich hier wieder zu sehen , danke für deine Antwort.
Wir benutzen FAMOS V8.7.1. Unter Parameter haben wir mehreren Werten eingeführt, auch VelSet.

Das Beispiel war nur ein Abschnitt aus dem ganzen vom FAMOS (nach Import) generierten Programm. Obwohl auf dem ABB Roboter Code - „Original im ABB Roboter“ die Daten richtig sind, sind die im FAMOS und im danach generierten Programm fehlerhaft, Code – „In FAMOS nach Import“.

Bei Famos-Output, am Anfang, kommen wie immer Projektdaten, LOCAL VAR und PERS robtarget. Dann kommen die Routinen mit Move – Befehlen. Die oberen Code Abschnitte sind davon.
Interessant ist, dass dieser Fehler nur am Ende des Programms aufgetreten ist, ersten 1000 Move Befehlen mit VelSet waren i.O.. Ich habe auch Gefühl, dass dieser Fehler nur in der Verbindung mit MoveC entsteht, bei MoveL/J habe ich noch sowas nicht erlebt. Kommt aber MoveC, dann kann dieser Fehler auftreten.

Hast du irgendwelchen Ideen? Gab es schon solche Meldungen bei euch im Haus?

Grüß
Bocmok

Hallo zusammen,

ich habe ein Problem mit Re/Import von Programmmodulen. Wir haben im Haus OLP FAMOS und ABB Roboter. Wenn ich mein Programm am Roboter kontrollieren will, muss ich manchmal die Orientierung von einigen Punkten, direkt am Roboter, ändern. Damit diese Änderungen auch in FAMOS Projekt übernommen werden, importiere ich den geänderten Modul zurück in FAMOS und zwar so: „Datei offen / nur Orientierungen und Positionen aktualisieren“.
Und da kommt es zu dem Problem: im so geänderten Projekt werden manchmal die Override-Werte um einigen Positionen verschoben, oder gehen ganz verloren...

Das passiert nicht immer, aber wenn es passierte, dann merkt man nicht, dass das Programm mit falschen Parametern läuft....

Als Beispiel: MoveC laufen am Bauteil, außerhalb wird mit OV 100% und MoveL rausgefahren und leicht umorientiert mit MoveJ

Original im ABB Roboter

PROC DR_1()
  !~#GroupName#DR
  ConfL\ON;
  ConfJ\ON;
  VelSet 100, 5000;
  MoveJ p10010,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10020,v275,z5,t_KP_200\WObj:=wobj_1;
  VelSet 50, 5000;
  MoveC p10030,p10040,v275,z5,t_KP_200\WObj:=wobj_1;
  VelSet 45, 5000;
  MoveC p10050,p10060,v275,z5,t_KP_200\WObj:=wobj_1;
  VelSet 100, 5000;
  MoveL p10070,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveJ p10080,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10090,v275,z5,t_KP_200\WObj:=wobj_1;
  VelSet 40, 5000;
  MoveC p10100,p10110,v275,z5,t_KP_200\WObj:=wobj_1;
  VelSet 100, 5000;
  MoveL p10120,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10130,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10140,v275,z5,t_KP_200\WObj:=wobj_1;
 ENDPROC

In FAMOS nach Import:

PROC DR_1()
  !~#GroupName#DR
  ConfL\ON;
  ConfJ\ON;
  VelSet 100, 5000;
  MoveJ p10010,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10020,v275,z5,t_KP_200\WObj:=wobj_1;
  VelSet 45, 5000;
  MoveC p10030,p10040,v275,z5,t_KP_200\WObj:=wobj_1;
  VelSet 100, 5000;
  MoveC p10050,p10060,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10070,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveJ p10080,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10090,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveC p10100,p10110,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10120,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10130,v275,z5,t_KP_200\WObj:=wobj_1;
  MoveL p10140,v275,z5,t_KP_200\WObj:=wobj_1;
 ENDPROC

Hat jemand Ideen woran es liegen kann und wie man das vermeidet???

Hallo RMILF,

eigentlich hat der Robi keine lineare Bewegung. Da er (normalerweise) nur Drehachsen hat, macht er nur Winkelbewegungen und die Zusammensetzung von diesen macht eine lineare TCP-Bewegung. Um deine Theorie zu kontrollieren, kannst du die TCP-Speed an analogen Ausgang setzen und die Werten beim Ablauf eines Programms mit konst. Geschwindigkeit aufnehmen. Das Programm soll dann eine MoveL von A zu B haben, dann MoveC von B zu D über C, mit nur Achse6, d.h. alle Achsen bleiben im Raum stehen, nur die 6. sich dreht. Kontrolliere dann die aufgenommene TCP-Speed Werte.
Aus meiner Erfahrung gibt es TCP - Geschwindigkeitsreduzierungen, weil der Robi versucht Bahn/Punkttreue zu fahren.

Grüß

Hallo Roland,

vielleicht hilft dir meine Antwort:
vor längerer Zeit, als ich noch mit ManutecR15 arbeitete, hatte ich auch so einen Fall. In roboterspezifischer Sprache wollte ich den Robi in "Werkzeugbezogene" Bewegungsart umorientieren und da war es genauso wie bei dir, Umorientierung um die zwei Achsen unterschieden sich nur in der Richtung +/-. Es kam heraus, dass es nur bei einigen Robi-Positionen (an der Grenze der Reichweite?) passiert und nur wenn man den Robi nur um ein Paar Grad dreht. Wenn man größere Winkeländerung machte, dann sah man, dass es doch die Bewegungen um die unterschiedlichen Achsen waren.