i.d.R. ist es einfacher einen Integer zu übertragen und den in der Case Anweisung im Cell auszuwerten und dann das entsprechende Unterprogramm zu starten
Je nachdem wie ähnlich sich die Bahnen sind reicht doch vllt auch ein Unterprogramm und du überträgst nur die Punkte an den Roboter?
Alles anzeigenganz einfache Lösung:
entsprechende Hersteller:in von Laserscanner:in abfragen und vergleichen - könnte man:in machen!
Im Ernst:
Alle Hersteller liefern entsprechende Unterlagen zu Berechnung der notwendigen Daten- muss man vielleicht suchen
Wie haltet Ihr denn vom Gendern?
Da hast Du Dir eher die Antwort etwas einfach gemacht.. Hersteller liefern zwar Daten, die eine sicherheitstechnische Betrachtung ermöglichen, aber wie hofd schon gesagt hat: Das hängt von vielen Faktoren ab und sollte grundsätzlich von einer zertifizierten Person erfolgen, die auch ihren Kopf dafür hinhält
Alles anzeigenHört sich nicht gerade vertrauenserweckend an..
Grundsätzlich gibt es (nach meinem Wissensstand) bzgl Einhausung 2 Möglichkeiten:
1. Der Maschinenbau sichert durch die Zelle mechanisch soweit ab, dass der Robi nicht raus kann. Geht z.b. durch entsprechend massive Schutzzäune, mechanische Anschläge oder genügend Abstand zwischen Robi und Zellwand
2. Der Robi wird softwareseitig (FEHLERSICHER!!!) abgesichert. Hierfür gibt es von den Herstellern Optionspakete wie z.b. Safe Operation Technology. Auch wenn der Robi bei dieser Option daran gehindert wird, aus seinem Bereich zu kommen, muss hier der Bediener daran gehindert werden, zum Robi hin zu kommen -> simple Einhausung reicht hier aus
Lies dir unbedingt mal die Gefährdungsbeurteilung/CE durch, hier MUSS der Anlagenbauer was drin stehen haben, wie sie hier vorgehen. Auch wenn es "nur" ein 6kg Robi ist, ist er eine ernstzunehmende Gefahrenquelle und eigentlich immer der Gewinner im Kampf Mensch gegen Maschine!
So kenne ich das auch.. Alles andere ist soweit ich weiß nicht (mehr) zulässig
Ich habe jahrelang Stäubli, Kawasaki und KUKA programmiert und bin jetzt in einem Unternehmen gelandet, dass hauptsächlich FANUC einsetzt...
Die Programmierung im FANUC selber ist lkeicht umständlicher finde ich, wobei man sich schnell daran gewöhnt..
Das, was ich bei FANUC wirklich schlimm finde und für mich auch ein No-Go, ist, dass es keine vernünftige Offline Programmierumgebung gibt. Es gibt Roboguide, dass aber nicht mit Workvisual, KIDE, oder der Umgebung von Stäubli (komm gerade nicht auf den Namen) zu vergleichen ist..
Ich habe mir für Notepad++ ein FANUC-Addon runtergeladen, womit es etwas erträglicher ist.. Aber kein vergleich zu den anderen...
Falls jemand noch eine bessere Möglichkeit kennt, dann bitte BEscheid sagen! 
Hallo,
explizit zu Deinem Fall kann ich nichts sagen, aber generell sind Gleitkommazahlen über Schnittstelle häufig ein "Problem".
Meistens behilft man sich einfach indem man in der Quelle einen Int baut (z.B. Multiplikation mit 100, d.h. 1,23 * 100 = 123), die Zahl als Ganzzahl über die Schnittstelle schiebt und beim Ziel wieder entsprechend durch bspw. 100 teilt (123 / 100 = 1,23) und damit weiterarbeitet.
Hallo,
ich würde am Anfang des Programms einen Offsetwert als Register deklarieren und dann jeden Punkt um den Offsetwert verschieben.. So brauchst Du nicht jedes mal jeden Punkt zu ändern und könntest den Offset auch über eine Schnittstelle (z.B. von einer SPS) einlesen und bequem über ein HMI ändern oder so.. Schwer zu sagen, ohne die Gegebenheiten zu kennen..
P.S. Ein etwas aussagekräftigere Threadbezeichnung wäre nett gewesen
Das gleiche Problem hatten wir mit Revision X... Nach Rücksprache mit Fanuc war die Ursache ein Bug in der Version. Wir sollten dann Revision T installieren und auf Revision X updaten, bzw. Revision X drüber installieren... Das hat auch geklappt..
Die RevT haben wir direkt von Fanuc bekommen
Ist schon etwas her, dass ich einen Kuka vor der Nase hatte, aber ich meine aus der Hüfte geschossen, das es
DECL SIGNAL OutDruckregler $OUT[172] TO $OUT[187]
heißen müsste und dann kannst Du direkt
OutDruckregler = 25
verwenden...
So wie es DS beschrieben hat und dann die kartesische Arbeitsraumüberwachung einfach erst "scharf" schalten, sobald ein gültiges Tool gesetzt worden ist.
If(VarState("$POS_ACT") == #INITIALIZED THEN
....
ENDIF
Wie gesagt, Stäubli arbeitet vom Prinzip genauso.. Guck mal im Handbuch nach waitEndMove() und wait
Ich glaube jeder Roboter hat einen... Wie sollten sonst Funtkio0nen wie z.B. Überschleifen funktionieren..? Aber kann es nur von Kuka, Stäubli und Kawasaki sicher sagen.. Ob andere Hersteller andere Lösungen haben weiß ich nicht.. 
Grundstellungsfahrt über Positionsvariablen finde ich persönlich immer etwas unglücklich, bzw. versuche ich das zu vermeiden, da der Roboter auch zwischendurch von Hand verfahren worden sein kann o.ä. .. Das müsste man abfangen.
Sofern die Fahrwege nicht zu komplex sind, würde ich eher die aktuelle Position auslesen und dann aus einzelnen Bereichen eine sichere Rückzugsstrategie programmieren.. Das ist häufig auch gar kein so großer Aufwand und ist meiner Meinung nach die sicherere Variante
Der Programmvorlauf funktioniert bei Stäubli genauso wie bei anderen auch.. Der arbeitet das Programm ab und lädt unterwegs alle Bewegungen in den MotionStack, sofern es keinen Vorlaufstopp gibt.. Den kannst du z.B. mit einem waitEndMove() erzeugen
Da fehlt am Anfang noch ein XP2=XP1. Ist genau das, was ich oben in blumigen Worten beschrieben habe.
Stimmt.. Das habe ich vergessen.. Vielen Dank für die Ergänzung 
Ich weiß^^ Wollte das nur nochmal mit einem Beispiel etwas anschaulicher machen
das einzige Maß, dass sich ändert ist die dicke des Baumstammes? Ich verstehe den Ansatz.. Ihr wollt einfach eine Begrenzung für die Bewegung haben ohne die Arbeitsraumüberwachung zu nutzen..
Mir fällt außer Punkte teachen keine brauchbare Lösung ein..
Generell würde ich aber vorschlagen, ein kurzes Programm zu schreiben, bei dem man am Anfang einfach die Variablen für den Baumstamm, bzw. die Fräsung rein gibt (Dicke, des Stammes, Breite und Tiefe der Fräsung etc.) und dann den Startpunkt auf Mitte des Stammes, oder Auflagefläche des Stammes teachen.. Dann kannste (auch im Handmodus) das Programm (ist nur eine Schleife, also in 20-30 Minuten programmiert) abfahren und alles ist fein.. Dann müsste jemand nur den Knopf für die Fahrfreigabe gedrückt halten und das Ganze mit "von Hand nochmal 1cm in X verfahren etc." entfällt dann auch alles.. Ist super einfach und schnell gemacht
Du kannst einfach einen Punkt erstellen und den entsprechend teachen und dann im Handmodus anfahren.. Dann hält er automatisch an
XP1 einfach als Referenz lassen wie er ist und nur XP2 ändern und anfahren
Case 1: XP2.x=XP1.x + 10;
Case 2: XP2.x=XP1.x +20 ;
SPTP XP2
PTP = fahre den Punkt an, egal wie, ohne Rücksicht auf Verluste
LIN = Halte die Bahn, ohne Kompromisse
Überschleifen = Guck, dass Du auf der Bahn bleibst, aber ein wenig Abweichen darf sein
.. so würde ich es mal interpretieren wollen ..
Finde ich etwas missverständlich... Sowohl bei PTP als auch bei LIN wird der Punkt grundsätzlich erstmal ohne Rücksicht auf Verluste angefahren (sofern keine Kollisionserkennung aktiv etc.)
Bei einer PTP Bewegung wird der Punkt halt als Achsbewegung angefahren (Alle Achsen fahren gleichzeitig los und kommen gleichzeitig an), was zur Folge hat, dass eine PTP Bewegung immer eine Kreisbahn ist, mal mehr, mal weniger ausgeprägt und ist die schnellere Bewegung.
Eine LIN Bewegung ist halt immer eine gerade Linie von Punkt A nach Punkt B und kann dafür mal durchaus länger dauern, weil bspw. Achse 4 sehr viel drehen muss o.ä.
Überschleifen hat auch nichts mit der Bahn, sondern mit dem Punkt auf der Bahn zu tun.
Wenn von Punkt A zu Punkt C über Punkt B gefahren werden soll, kann der Punkt B (je nach Platz) überschliffen werden, d.h. er wird nie tatsächlich erreicht. Der Roboter verlässt im Abstand von x (definierbar) die Bahn von A nach B und wechselt auf die Bahn von B nach C.
Der Vorteil ist, dass der Roboter sonst Punkt B anfahren würde, vollständig halten und wieder beschleunigen muss.. Ist für die Taktzeit eher nicht so toll ...
Und Deine Sorge in Z-Richtung, die ist aus meiner Erfahrung her unbegründet. Der Endpunkt müsste schon relevant "tiefer" liegen, als der Startpunkt, dass der Rob eine Furche zieht.
Frohes Neues gewünscht ..
So unbegründet ist das nicht.. Wenn die Achsbewegung so aussieht, dann kann die Kreisbahn auch durch den Tisch gehen..
Das ist der Grund, warum man seine Programme zuvor testet.
So würde ich das auch sehen^^
Im Zweifel einfach eine Orientierung fest definieren oder noch eine Zwischenposition oberhalb des Tisches setzen und die angemessen überschleifen
Du könntest auch eine Abfrage schreiben die in etwas so aussieht:
if ($AXIS_ACT.E2 < rAltPosE2 - 1.0) AND ($AXIS_ACT.E2 > rAltPosE2 + 1.0) then
so kannst Du auch die Genauigkeit recht einfach steuern (z.B. mit Faktor 0,1 oder 10)
Du musst einfach einmal auf "save" drücken.. Gibt es unten in der Leiste eine Taste für (F8?) .. Auch nach dem Teachen der Punkte muss gespeichert werden.. Sonst sind nach einem Neustart alle Änderungen wieder verschwunden..
