Um welchen Hersteller geht es denn? Es gibt ja i.d.R. eine Fahrfreigabe und einen Hintergrundprogramm (Submit bei Kuka z.B.) ... Da machste einfach eine Abfrage rein und entziehst die Fahrfreigabe, wenn das Signal wegfällt..
Posts by AlexRobo
-
-
Hat sich aufgeklärt.. War noch ein Fehler in der SPS.. Roboter hat getan was er soll! Trotzdem vielen Dank!
-
Hallo zusammen,
es ist schon eine Weile her, dass ich den letzten Kuka vor der Nase hatte und jetzt habe ich ein etwas merkwürdiges Problem:
Ich fahre auf eine Position, schalte einen Ausgang, Warte auf einen Eingang und will dann weiterfahren. In T1 läuft er durch und fährt aber direkt weiter, obwohl das Signal noch ansteht. Der Ausgang wird auch nicht geschaltet. Nur wenn ich per Satzanwahl direkt in dem jeweiligen Satz starte, wird die Anweisung korrekt ausgeführt (der Ausgang wird geschaltet und auf den Wegfall des Eingangs gewartet).
Jemand eine Idee woran das liegt?
Vielen Dank!
LIN XPOS_ElektroAbdeckungS2
; Roboter in Position Prüfung der Elektronikabdeckung
in_pos_EAbdeckung_A76=TRUE
;
; Warte auf nicht anfahren Prüfung der Elektronikabdeckung
WAIT FOR NOT Anf_LT500_2_EleAbd_E76 ; OR Anf_Homepos_E48
;
; Roboter verlaesst Position Prüfung der Elektronikabdeckung
Zylinder_GS_A77 = true
Zylinder_AS_A78 = false
in_pos_EAbdeckung_A76 = FALSE
;
LIN XPOS_ElektroAbdeckungS2: {X 0, Y 50,Z 0,A 0, B 0, C 0} C_DIS -
Vielen Dank für eure Antworten.
Das Problem können wir trotzdem nicht lösen.
Bei jedem Teil, den wir ablegen, sind die Werte der X, Y, Z, A, B und Z-"Achsen" immer unterschiedlich, bedingt durch die Bauform der Teile. Sind insgesamt 50 Teile, die wir ablegen müssen.
Das Problem wurde schon erklärt.. Aber auch verstanden? Excel ist nicht das richtige Tool um die Punkte zu berechnen..
Ich vermute mal wild drauf los: Ihr habt niemanden, der sich mit Kuka wirklich auskennt, geschweige denn mit den Grundprinzipien die einem Roboter zugrunde liegen? Ist grundsätzlich nicht schlimm.. Scheinbar seid ihr bisher auch so klar gekommen.. Aber um Probleme wie dieses zu verstehen und zu lösen, muss man sich etwas intensiver mit dem Thema beschäftigen. Die richtigen Begriffe um damit anzufangen sind hier ja schon mehrfach genannt worden...Viel Erfolg!
-
Was genau fehlt Dir an Info? Du legst den Greifer in der Kamerasoftware mit den CAD Daten an und dann hat er in der Kamerasoftware eine Nummer. Die Kamera übergibt dann ein Array an Positionsdaten und ein separates Array mit der Greiferkennung. Das musst Du dann nur auswerten.
So in der Art sollte Deine Schnittstelle aussehen: -
Jeder macht halt seiner Erfahrungen.. Ich habe das noch nie so erlebt..
-
Wir haben auch eine Keyence CV-X480D im Einsatz mit 2 Fanux Robotern und die Kamera ist auf einer Linearachse die 14 Palettenplätze abfährt und Bilder macht.
Das ganze kommuniziert über eine Siemens SPS per Profinet. Die Kamera gibt Koordinaten und Winkel in mm, bzw. Grad raus, die dem Roboter direkt übergeben werden können (je nachdem mit einem Offset). Dieser fährt das ganze dann einwandfrei an und holt das Teil. Das funktioniert einwandfrei.
Zusätzlich gibt es über die Schnittstelle noch die Greiferkennung (die CAD Daten der Greifer liegen in der Kamera und werden im Kamerajob hinterlegt), so weiß auch der Roboter mit welchem Tool er den ganzen Spass anfahren soll.Fa. K. ist immer gern dabei zu helfen - wenn man dafür löhnt. Für lau kriegst Du kaum Infos.
Das würde ich so nicht unterschreiben.. Keyence hat uns immer gut supportet und auch vieles ohne Entlohnung gemacht Allerdings würde ich auch das Telefon und nicht den Mailkontakt empfehlen.
-
Welche Parameter bekommst Du denn von der Kamera? Die komplette Position, oder nur XY? Solange Du keinen geänderten Z-Wert übernimmst (je nach Koordinatensystem) und die WInkel ggfls limitierst, sollte es da keine Probleme geben.
-
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?
-
ganz 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
-
Hö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