Abhilfe könnte schon das Verwenden von FRAME statt E6POS bringen.
Danke! Werd ich ausprobieren!
Und inzwischen bin ich auch vornherein schlauer und poste solcherlei Dinge gleich mit
Abhilfe könnte schon das Verwenden von FRAME statt E6POS bringen.
Danke! Werd ich ausprobieren!
Und inzwischen bin ich auch vornherein schlauer und poste solcherlei Dinge gleich mit
Alles anzeigenE6POS deutet ja darauf hin, dass Du Status und Turn mit übergibst. Bist Du da PTP unterwegs oder LIN? Falls PTP, bist Du sicher, dass der Achsbegrenzungsfehler explizit A6 erwähnt? (Ich weiss, ist eine vordergründig dumme Frage, aber tatsächlich kann es vorkommen, dass der Robbi versucht, A1 hintenrum zu drehen, das im Vorfeld schon aufgibt, und man sieht in der Fehlermeldung den Wald vor lauter Bäumen nicht....)
Generell hab ich bei sowas auch immer eineWhile-Schleife eingebaut (While winkel > 180 do winkel=winkel - 360 und andersrum auch dahinter), um die Angabe Modulo 1 Umdrehungsbereich zu bekommen.
Bei E6Pos gibt es kein A6, sondern nur A als Bestandteil einer Orientierung, A ist REAL.
An Deiner Stelle würde ich die Vorposition als POS oder E6POS anfahren bzw. derart sicherstellen, dass die Armkonfiguration stimmt, und dann nur noch mit FRAMES arbeiten. Den aufgeschlagenen Winkel (evtl. nach obig beschriebener Normierung, Schlauchpakete etc. beachten) dann in einen eigenen Frame werfen (korrwinkelframe=$NULLFRAME; korrwinkelframe.a=korrekturwinkel) und per Doppelpunkt an den Zielframe hängen:
LIN originalposframe:korrwinkelframe (setzt voraus, dass das Greiftool zentrisch ist, aber das muss es auch schon vorher gewesen sein, sonst geht es ja eher nicht.)
Ich bewege mich mit PTP über die Position, dann mit LIN in ein Sackloch was auch klar Lineares Verfahren benötigt.
Ich werd mir deine Vorschläge für das nächste Mal aufschreiben wenn ich wieder an dem Roboter bin.
Danke dafür!
Aktuell hab ich es halt hintenrum gelöst dass der Roboter bei bestimmten Winkeln nicht mehr fährt sondern den nächsten Takt beginnt. Das Teil wird dann NiO...
so umgehe ich wenigstens das Problem. Tritt ja nur bei vllt 2% auf.
das kannst du in den Optionen ändern.
das funktioniert bei mir leider auch nicht... Option ist schon längst aktiv aber alle Folds sind offen beim öffnen eines Moduls
über den Button kannst du Optionspakete installieren
Hallo zusammen,
ich habe folgendes Problem:
Es geht um die korrekte rotatorische Ausrichtung eines zylindrischen Werkstückes nach einer Durchgangsbohrung.
Bei einer Position wird durch eine vorherige Berechnung eine Verdrehung auf A aufgerechnet. Das funktioniert auch hervorragend, bis manchmal (scheinbar völlig zufällig) ein merkwürdiger Wert errechnet wird (wobei der bisher immmer -34.xxx war) der die Achse 6 in den Softwareendschalter treibt. Ausgangsposition ist die Achse 6 bei -28Grad während der Winkel A 0.00 beträgt. Darauf wird dann der vorher berechnete Winkel aufgerechnet. Man hat also in jede Richtung mehr als genug Rotation übrig um das Werkstück mehr als 180 Grad zu drehen.
Ich hätte nun gerne mit einem Interrupt die Situation abgefangen in der die Zielposition bei >345Grad nicht mehr angefahren wird. (oder was immer funktioniert, falls jemand Vorschläge hat)
Meine Versuche bisher waren:
in der sub.sps (USER PLC):
position_aktuell = $POS_ACT
in dem besagten Programm dann:
INTERRUPT DECL 4 WHEN position_aktuell.A6 >= abbruchwinkel (wenn es eine Positionsvariable war: abbruchwinkel.A6) DO winkel_ueberschritten()
wobei position_aktuell als E6POS und abbruchwinkel in verschiedenen Verusuchen als REAL, als INT, als E6AXIS mit {A1-A5 0.00, A6 -345} und als E6POS Variable deklariert waren.
Die Variablen gingen aber nie zusammen. Laut Panel Syntaxcheck gehörten die alle nicht zum Typ der E6POS.
Ich habe als nächstes dann versucht $AXIS_FOR (in der Doku gefunden) mit E6AXIS Variablen abzugleichen. Hat aber ebenfalls nicht funktioniert. Ich hatte den Befehl position_aktuell=$AXIS_FOR vor den eigentlichen Bewegungsbefehl und eine IF Abfrage gesetzt. Da ergibt $AXIS_FOR aber keine nutzbaren Werte.
Falls bis hierhin jemand durch meinen Kauderwelsch durchgeblickt hat, kann mir bitte jemand einen Tipp geben?
Ich bin etwas ratlos und würde ungern einfach die Holzhammermethode ( IF (Winkel < -34 AND > -35) THEN Winkel=Winkel +1) anwenden
um den (scheinbar kritischen) Winkel -34Grad zu übergehen.
Gruß
Moin zusammen, ich stehe vor einem Problem beim palettieren. Ich möchte eine Funktion realisieren bei der ich die RCL Anzahl flexibel erweitern kann. Außerdem möchte ich dass der Startpunkt und die Anzahl der zu bewegenden Teile flexibel bleiben (Start und Anzahl durch die kollaborierende CNC Maschine vorgegeben). Als Beispiel : eine Palette mit 10 Teilen in 14 Reihen und 1 Schicht bei der nach Bedarf bei Teil 11 gestartet Und nach 20 Stück wieder beendet werden soll. Gibt es eine Möglichkeit die Palettierfunktion dafür zu nutzen, EX oder BX? Ich bin darin bisher nicht auf die Möglichkeit gestoßen solche Positionen flexibel zu bestimmen. Ich hatte überlegt in das Palettier Register bei I, j, l Register zu schreiben aber das scheint nicht zu funktionieren.
Bisher sieht es so aus als ob ich dafür ziemlich aufwendig mit offset oder Baseverschiebungen arbeiten muss, was sicherlich diverse Tests und Zeit beansprucht. Hat hier vielleicht jemand einen Tipp oder sowas schon mal realisiert?
Danke schonmal und ein schönes Wochenende
Solange kein TCP vermessen ist, nutzt der Roboter bei anwählen von Tool die Flansch koordinaten und die Ausrichtung also quasi werkszustand. Das selbe bei User, bloß eben mit dem World koordinaten System
Achso und die restlichen sind tool was die Bewegung im Bezug zu einem vermessen en TCP ist und user sind vermessene Basis frames
JGFRM ist ein externes koordinaten System und World entspringt dem Roboter Fuß, bei fanuc aus dem Rotationspunkt der Achse 2. JGFRM benutzt man für bspw Klebedüsen oder ähnliches die nicht am Roboter angebracht sind. Muss wie jedes frame ausgerichtet und vermessen werden