Hi Maddin,
beim Senden des Bootprojektes, wird eine Datei auf die Festplatte des Roboters kopiert. Diese Datei wird bei einem Bootvorgang genommen und eingelesen. D.h. ein Bootprojekt musst du nicht gesondert aktivieren.
Nur wichtig ist das man es nicht vergisst zu übertragen 
Hi,
die Frage ist natürlich auch was man damit machen will.
das System dahinter müsste natürlich die selbe Geschwindigkeit verarbeiten können.
Ich weiß von ProConOS mit Motion Drive, das man dieser mehr Zeitscheiben zuordnen kann.
So wären es bei 2 Zeitscheiben ein Interval von 6 ms.
Aber das bringt dich vermutlich bei deinem Kamera Problem nicht weiter.
Gruß
Hallo,
habe gerade in der Dokumentation von KUKA.RoboterSensorInterface geschaut.
Da steht aber auch max. im IPO-Takt von 12 ms.
Grüße
Andreas
Hallo,
das manipulieren des Overrides von extern ist aus diesen Gründen auch von KUKA nicht gestatet.
Zumindest wenn man SafeRobot einsetzt gibt es einen Absatz "Single Point of Control" was dieses nicht erlaubt.
Da es aber ganz oft vom Kunden gewünscht wird, ist es wohl trotzdem sehr oft im Einsatz.
Würde zumindest das verändern des Overrides nur in Automatik zulasen, da ich sonst fe_001 völlig recht gebe.
Mich hätte es auch schon fast mal getroffen.
Grüße
Hallo,
die Info hatte ich bei meinem aktuellen Projekt auch.
Jedoch hat mir KUKA anschließend mitgeteilt, dass sie noch nicht Freigegeben ist.
Weißt du ob WorkVisual 3.0 inzwischen Freigegeben ist?
Grüße
Hi RobbiTobbi,
hatte ich auch gedacht, dass dies ev. mir helfen könnte.
Leider ist diese Funktion ganz einfach über die Software über eine Variable de- / aktivierbar.
D.h. dies ist keine sichere Funktion.
Wenn dann muss man wie du schreibst über sicher überwachte Geschwindigkeit dies zusätzlich absichern.
SPC steht für die japanische Fernsehserie "Samurai Pizza Cats", was aber hierbei nicht gemeint ist.
In diesem Fall steht es für "statistische Prozesskontrolle" und bedeutet das zyklisch Teile nach einer Bearbeitung entnommen, auf ihre Qualität kontrolliert und dem Prozess wieder zugeführt werden. Für den Roboter nichts anderes als dem Bediener Teile aus zu geben und wieder entgegen zu nehmen.
Normalerweise funktioniert dies über eine Schublade am Schutzzaun.
Hier fangen die Probleme an.
- Roboter muss bis an den Schutzzaun fahren. (Je nach Größe der Schublade)
- Erhöhte Bedieneraktionen in diesem Bereich
- Eingreiffen des Werkers mit gesamten Arm (Schutzbereich auf 850 mm vergrößern)
Hi,
danke für deine Antwort.
Ich will lediglich Erfahrungen sammeln, wie andere dies Umsetzen, du brauchst also keine Sorge wegen Haftung zu haben.
Mich würde aber trotzdem interessieren, wie euer Kunde auf 200mm kommt?
Ist dies ein richtwert, die bei diesem Kunde so üblich ist?
Die Finger habe ich bis jetzt noch überhaupt nicht mit berücksichtigt, da wir überlegen Makrolonscheiben zu verbauen.
Laut KUKA Dokumentation hast du aber bei einer Auslenkung von 60% immer noch einen Nachlaufweg von 848mm.
Wenn ich es noch richtig im Kopf habe, bringt eine Reduzierung der Last nicht sonderlich viel weniger weg.
Wenn du schaltbare Bereiche ansprichst, nutzt ihr auch SPC Schubladen?
Wenn ja, wie weit liegen diese vom Schutzzaun entfernt?
Hier haben wir im speziellen immer die größten Probleme.
Grüße
Hallo Zusammen,
mich würde mal von euch interessieren, wie ihr SafeRobot in der Praxis einsetzt.
Im speziellen geht es mir um den Zellbereich und die Nachlaufwege des Roboters.
KUKA schreibt in der Dokumentation sehr einfach, dass der Systemintegrator diese Nachlaufwege in der Parametrierung mit berücksichtigen muss!
in der Roboterdokumentation ist unter Anhalteweg für einen KR210 R2700 extra in der Achse 1 bei 100% Geschwindigkeit min 30°-49° Nachlaufweg angegeben.
Angenommen der Roboter ist beim verlassen des Zellbereichs bei 100% Geschwindigkeit und hat eine Auslenkung von 60% (1620 mm) dann habe ich einen Nachlauf von 848 mm. Bei 100% Auslenkung wären dass dann 1414 mm.
D.h. mein virtueller Schutzzaun müsste ca. 1,5 m weiter innen liegen als der echte Schutzzaun.
Welcher Anlagenbauer hat denn bitte soviel Platz oder soviel Zeit um so langsam zu fahren?
Oder habe ich generell ein Problem mit dem Verständnis?
Habe auch schon mit KUKA telefoniet, ohne Ergebnis.
Danke für eure Antworten
Hi,
also ich würde die Idee mir den schnellen Messeingängen weiter verfolgen.
Wenn ich es richtig in Erinnerung habe, sind die schnellen Messeingänge unabhängig vom IPO-Takt.
Das bedeutet du kannst auch schneller als alle 12ms Signale auswerten.
Hierfür wird dann extra ein Interrupt ausgelöst.
Die schnellen Messeingänge befinden sich bei der KRC2 auf der RDW am Roboterfuss.
Wenn man bei KUKA diese Funktion bestellt, wird die Abdeckplatte der RDW getauscht zu einer Abdeckplatte mit Stecker.
Der Ansatz mit den schnellen Messeingängen bietet dir den Vorteil das du unabhängig von der SPS.SUB bist.
Ich denke über die SPS.SUB wirst du für so etwas nicht glücklich werden.
Grüße
sollte als Ergänzung zum IrrerPolterer dienen.
Da siehst du wie der neue Treiber angesprochen wird.
DEVNET=2,dnInit,dn2drv.o
Aussderm die Info von KUKA das der Treiber ab Version 5.0 verwendet wird.
Trotzdem würde ich auch mal schauen, ob du den dn2drv.o findest.
Sollte in einem Verzeichnis mit den anderen Treibern liegen. Wo weiß ich gerade auch nicht auswendig.
Oder wie der IrrerPolterer sagt, einfach mal ausprobieren.
Grüße
Hallo,
das sagt meine iosys.ini.
Der Treiber wurde mit der Version 5.0 B13 getauscht.
Grüße
Andreas
; ATTENTION !!!! Since V5.0 Build13 we have removed the DeviceNet
; driver "dndrv.o". Now you have to use the driver
; "dn2drv.o" and the appropriate syntax (form 2)
[CONFIG]
VERSION=2.00
[DRIVERS]
;CNKE2=21,cnke2CPInit,cnke2drv.o
;DNSC6=20,dnsc6Init,dnsc6drv.o
;DNSC5=19,dnsc5Init,dnsc5drv.o
;DNSC4=18,dnsc4Init,dnsc4drv.o
;DNSC3=17,dnsc3Init,dnsc3drv.o
;CNKE1=16,cnke1CPInit,cnke1drv.o
;INTERBUSPCI=15,ibsCPPciInit,ibpcidrv.o
;DSEIO=14,dseIoInit,dseiodrv.o
;DNSC2=13,dnsc2Init,dnsc2drv.o
;DNSC1=12,dnsc1Init,dnsc1drv.o
PBMASL=11,pbmsInit,pfbmsdrv.o
DEVNET=2,dnInit,dn2drv.o
Hi,
habe gerade vor kurzem auch ein DevNet mal wieder inbetrieb genommen.
Vielleicht folgender Tipp.
Erst mal alle Einträge wieder entfernen, so das nur der Treiber aktiv ist.
Speziell in der iosys.ini sollte keine Projektierung vorhanden sein.
Die macid=1 kannst du auch mal auskommentieren.
Dann macid an deinem Modul noch mal kontrollieren.
24V am Modul und auf dem Bus kontrollieren.
Modul noch mal Spannungslos machen und wieder einstecken.
Dann im Telnet prüfen welche Teilnehmer auf deinem Bus liegen.
Jetzt sollte zumindest mal das Gerät mit der MacID antworten.
Dann weißt du schon mal das dein Busaufbau in Ordnung ist und kannst mit der Projektierung beginnen.
Bei meinem Busaufbau hat so ein Witzbold an den beiden Enden einen Endwiederstand rein gehauen und zusätzlich auf dem Multipowertab noch einen.
Und dann hate er auch noch die Meinung, dass das so gehört
Viel Glück...
Die rede ist vermutlich von WinAC.
Ich weiß das bei ProConOS ein File namens ... Wie war der name noch mal?
Bootprojekt.pro???
Diese Datei wird beim Hochfahren der KRC in ProConOS geladen und gestartet.
Vermutlich wird es bei WinAC gleich gehandelt.
Aber wie die Datei heißt und warum sie plötzlich alt ist, kann ich dir auch nicht sagen.
Bei ProConOS musste man das File seperat übertragen, da ist es häufiger vorgekommen das nach einem Booten ein altes Projekt aktiv war.
Hi,
da dein messwertultra ein Signal ist und auf die physikalischen Eingänge zugreift stoppen die Abfragen deinen Vorlaufzeiger.
Du kannst es mal mit einem CONTINUE vor den while Schleifen versuchen.
Doch bedenke, wenn du Advance auf 5 stehen hast, wird dein Ergebnis nie zufriedenstellend sein.
Dein Vorlaufzeiger wäre dann immer 5 Bewegungen vor deiner eigentlichen Bewegung.
D.h. wenn dein Messwert erreicht wäre, würde er trotzdem noch 5 Bewegungen machen.
Wenn du den advance auf 1 setzt, müsste dein Ergebnis bis auf +/- 2mm stimmen.
Gruß
Warum geht das nicht so?
Bei manchen Panels kann man doch die Option OPC-Client dazu bestellen oder nutzen.
Ist dann die Frage ob die Freigegeben sind.
Am KUKA müsste man dann die Option OPC-Server dazu bestellen.
Dafür sind die Komponenten ja gemacht worden.
Aber so wirklich Konfortabel ist das vermutlich auch nicht.
Schau mal ob du den Ausgang doppelt verwendest.
Wenn du z.b. die Spiegelung der Programmnummern im selben bereich hast, kann so etwas passieren.
Hallo,
ich weiß das es mal Probleme gab, wenn man die neue Karte von Siemens eingesetzt hat und die GSD-Datei von KUKA.
Irgendwann wurde dann auf die neue Karte von Siemens umgestellt.
Deswegen vermute ich das du da aufpassen musst.
Denke das es mit der alten GSD von Peter gehen müsste.
Gruß
Weiß jemand ab welcher KRC Version das zur Verfügung steht?
Habe hier eine KRC V2.2.8 und kann es nicht finden.
Danke.
Das kann ich bestätigen und es werden dann auch keien Ressourcen an ProConOS gebunden und natürlich auch kein Programm in ProConOS abgearbeitet.
Sollte eigentlich reichen.
Vielleicht noch den Router (Wenn nicht andersweitig benötigt) der mit installiert wird aus der Autostart von Windows raus schmeißen.
Gruß
