Hallo Demo,
wenn durch das Aufspannen des Teils es nötig wird ein Kamerasystem zu verwenden um die Löcher zu finden, würde ich als erstes das Spannkonzept und die Bauteilaufnahme hinterfragen. Evtl. ist ein teures Kamerasystem garnicht notwendig wenn sich der Konstrukteur etwas mühe gibt.
Hi,
was auch gehen könnte. Über CREAD, im SPS Sub, die Position in ein txt-File schreiben.
Liebe Grüße
Stimmt, die hätte ich jetzt doch glatt vergessen, wobei man unterscheiden muss zwischen der Geschindigkeitsreduzierung und der sicher überwachten Geschwindigkeit im Zellenbereich bzw. Überwachungsraum.
Wir haben die Geschwindigkeitsreduzierung aus, weil der Robi schon abgebremst wird, obwohl er den Zellenbereich/Überwachungsraum gar nicht verletzen würde sondern nur nah drann vorbei fährt. Das kann ziemlich nervig sein, kann aber die Lösung sein, wenn man Probleme mit den Abständen bekommt.
Hallo Ralf,
ich glaube in einem der Lehrgänge (KRC4) hieß es, wenn was am hydraulischen GWA ist, nicht versuchen zu reparieren sondern tauschen, da es in den meisten Fällen die Membran ist.
Gruß
RobbiTobbi
Erst mal danke für das nutzlose Wissen. 
Das Thema geht jetzt etwas sehr weit in die Simulation, da wird es schwierig ohne die Anlage zu kennen gute Ratschläge zu geben.
Grundsätzlich gilt, was nicht geht, geht nicht. Wenn die Konstruktion/Layout scheiße ist, kann es die Robotik auch nicht mehr retten.
Bei uns wird ein Roboter wegen einer Schublade, im Sinne von er zieht das Teil mit einer Schublade aus der Anlage, nicht Safe, da es kein ständiger Arbeitsplatz ist.
Wenn er mit dem Arm in die Anlage greifen muss, muss der Überwachungsraum entsprechend groß sein, so dass der Roboter mit ausreichend Abstand zum stehen kommt. Sprich Raum aktiv schalten und mal in T2 100% rein fahren und schauen ob die Abstände ausreichend sind.
Warum die 200mm gefordert sind, kann ich dir nicht sagen, da die ganze Konfiguration und die dazu nötigen Absprachen über die Simulation läuft. Ich darf das ganze nur zum laufen bringen.
Die Frage die du für dich erst mal beantworten musst ist: Was bedeutet sicher?
Wenn du das von KUKA vorgegebenen worst case Szenario als Grundlage nimmst, packst du den Robi am besten in ne Zelle in der er die Makrolonscheiben nicht erreichen kann.
Bei uns sind nur Robis safe geworden die in der Nähe von Einlege- oder Nacharbeitsstationen sind. Sprich erhöhtes Personenaufkommen.
In anderen Werken/Ländern sind, auf Wunsch des Kunden, alle Robis safe geworden die den Schutzzaun erreichen können, da die Qualifikation der Werker eine andere ist.
Öhm, was sind SPC Schubladen?
Hallo,
grundsätzlich hast du nicht ganz recht, weil du mit dem Abstand von 1500mm bei Vollgas, Vollauslage und Volllast nur 90mm Abstand zum Zaum hast. Wenn du Makrolon oder irgend etwas gleichwertiges in der Anlage hast, das verhindert dass der Werker seine Finger durch steckt ist das ok, bei nem standard Schutzzaun brauchst du wenn ich mich recht erinner 120mm.
Jetzt kommt das ABER. Wann hat man schon mal den Fall dass der Robi mit Vollgas, Vollauslage und Volllast in den Zellenbereich fährt? Es handelt sich mit Sicherheit um keine Programmierte Bahn, d.h. es MUSS ein Fehler in der Steuerung vorliegen und wie sich der Robi dann verhält ...
Bei uns ist es so, dass der Kunde 200mm Abstand zum Zaun fordert. Wir fahren den Zellenbereich von Hand in T1 an und messen den Horizontalen Abstand zwischen Zaun und Greifer/Bauteil (was halt näher ist). Was dabei natürlich zu berücksichtigen ist, sind die Werkzeugkugeln. Um sicher zu gehen ob der Absatnd wirklich passt am besten mit verschiedenen Greiferstellungen den selben Punkt am Zellenbereich anfahren um den kleinsten Abstand zu finden.
Was viel spannender ist, sind geschaltete Überwachungsräume, da dort im Regelfall eine programmierte Bahn hinführt und Arbeitsplätze sind. Da spielen die Abstände eine wesentlich wichtigere Rolle.
Zu KUKA: Wenn sie klug sind, werden sie dir keine Angaben zu irgend welchen sicherheitsrelevanten Abständen geben, da sie sonst angreifbar werden.
Zu Mir: Ich bin kein Sicherheitsingeneur, daher beruhen alle Angaben auf Erfahrungen durch Abnahmen der SafeOp innerhalb Deutschlands. Keine Gewähr auf Vollständigkeit oder Richtigkeit.
Liebe Grüße
RobbiTobbi
Ja, du kannst es auch mit einem Unterprogramm statt der Funktion machen.
Ich weiß zwar jetzt nicht was ein Brake in C auslöst, aber mit Wait for Fals, wartest du darauf, dass die Bedingung, in diesem Fall False, True wird. Also bleibt der Robbi in Wait for False hängen bis du ihn von Hand, mittels Satzanwahl, befreist. Mach ich gerne so, weil wenn er in den Default Zweig spring ist irgend etwas schief gelaufen, das kontroliert werden muss.
Alternativ kannst du auch nur ein Halt nehmen. Nach erneutem Startsignal läuft er dann einfach weiter.
Wenn du nur einen Ausgang setzen willst kannst du das natürlich auch tun statt dem Wait for False und den Zähler deiner Schleife hochsetzen. Damit solltest du dann auch aus der If-Schleife raus kommen.
Ich hab gerade mal eben schnell drüber geschaut.
Der Switch sieht soweit gut aus, bis auf, dass das Endswitch fehlt. Ich würde noch nen Default Zweig mit nem "Wait for False", einfach zur Sicherheit, rein machen.
Das ;Fold am Ende sieht komisch aus.
Da die Funktion einen Wert zurück gibt muss man diesen Wert auch einer Variablen zuweisen. Also B[]=Calculate(Reihenfolge), wobei ich mir gerade nicht sicher bin, ob man ganze Felder übergeben kann. Der Datentyp der Funktion fehlt, muss in deinem Fall Deffct Int Calculate(X1:Out) Und wie bereits oben beschrieben "muss" ein Return ans Ende der Funktion. Sowas wie Return (X2[]).
Das wars was mir so aufgefallen ist.
Hab gerade mal im Quickguide (für die KRC2) geschaut. Auf Seite 21 steht dort zu Funktionen unter anderem folgendes:
"-Eine Funktion liefert einen bestimmten Funktionswert an das Hauptprogramm zurück. Deshalb muss eine Funktion immer mit Return beendet werden."
"-Die Funktion besitzt zusätzlich einen Datentyp. Dieser muss immer mit dem des Funktionswerts übereinstimmten."
Da der KUKA den Typ Void nicht kennt (Quickguid Seite 3), sag ich mal nein. Die Funktion muss dir immer einen Wert liefern. Ob du nen festen Wert übergibst und was du dann mit diesem Wert machst ist was anderes. 
Also, du könntest für jede Naht einen Case machen und über eine Loop schleifer dir nach jeder Fertigmeldung von der SPS die nächste Naht geben lassen, dann könntest du dir aber auch gleich für jede Naht ein Hauptprogramm geben lassen.
Oder, wenn es nicht ganz so flexibel sein muss weil es nur eine Hand voll verschiedener Abarbeitungsfolgen gibt, könntest du diese in jeweils einen Case Packen. Also Case 1 (Naht 1,Naht 2,Naht 3,Naht 4,Naht 5,Naht 6) Case 2 (Naht 1,Naht 3,Naht 5,Naht 2,Naht 4,Naht 6) etc.
Oder, du kannst einen Mix aus den vorherigen Vorschlägen machen, wenn z.B. immer Naht 3 und Naht 5 hintereinander geschweißt werden die in einen Case dann Naht 4 alleine in einen Case etc.
Zum Thema Abstände hab ich da mal ein PDF von unseren Sicherheitsfutzies bekommen, nach denen die arbeiten. Ist natürlich nur für Deutschland, sollte aber für die meisten hier reichen.
Lieb Grüße
RobbiTobbi
Moin Harry,
ich hab gerade noch mal mit unserer "KUKA IBN Spezialistin" gesprochen und wir sind beide der Meinung, ohne es bisher probiert zu haben, dass es nicht so einfach geht. Speziel die Maschinendaten sind wohl empfindlich.
Was allerdings geht ist das Zusammenführen der Projekte. Das hat meine Kollegin schon erfolgreich gemacht, bei zwei unterschiedlichen Robotern.
Ich für mich habe entschieden, das Zusammenführen oder kopieren von WoV Projekten nicht zu machen. Ich trau der ganzen Sache nicht. Außer dem muss man eh die ganzen IP-Adressen im nachgang anpassen. Da kann ich die Bus-Konfiguration auch noch schnell mit machen.
Liebe Grüße
RobbiTobbi
Moin moin,
ich hätte die $ov_pro (Programmoverride) statt der $red_vel benutzt, weil man bei der $ov_pro im display sieht wie schnell der Robbi gerade unterwegs ist. Vor-/Nachteil ist, dass man die $ov_pro über die Tasten am KCP beeinflussen kann, also kann jeder dran rumspielen.
Liebe Grüße
Hallo BastelNerd,
ich kenne ein ähnliches Phänomen, wenn im Namen des WoV-Projekts ein Punkt ist.
Ab diesem Zeitpunkt läd er beim öffnen des Projekts in WoV, nur diese Version in der der Punkt ist welche nicht zwangsläufig die Ausgewählte ist. Bei der Bus-Konfiguration bin ich mir nicht sicher ob die betroffen ist, aber die ganzen Dateien im R1 etc. inklusive Config.dat sind es. Hat auch schon ne Clinchzange gekostet, weil plötzlich die Tool- und Base-Daten nichtmehr gepasst haben.
Ich hoffe das hilft dir weiter.
Ach ja, Lösung des Problems mit dem Punkt. Den WoV-Projektordner unter C:\KRC\USER\PROJECTROOT\ löschen.
Hallo Paulaner,
ich geh mal davon aus, dass du das Kabel und die Steckverbindungen zwischen Roboter und Murr Modul schon überprüft hast, daher würde ich bei Schreib- und Lesefehler zuerst mal die ID in den Master Einstellungen und auf dem Murr Modul prütfen.
In Modulkonfiguration ist mir aufgefallen, dass nur Pin 4 konfiguriert ist, jedoch nicht Pin 2.
Liebe Grüße
RobbiTobbi
