Beiträge von ottosieben

    Scheint, B_OUT(9) ist als Byte definiert. Mehr als 255 dezimal kann ein Byte nicht darstellen. Wer oder was versucht den Wert zuzuweisen?

    schon klar mit softwarebegrenzung. War als worst case gemeint.


    Ich hat mal nen ami kunden der angst hatte das die Regler hängen bleiben und der roboter sich bis in endanschläge dreht.

    Moin.

    Dann ist es gut. :thumbup:Ich hatte nur den spontanen Impuls , das richtig zu stellen. Gerade in diesem Fall, wo der TO offensichtlich neu im Metier ist, sollte aus meiner Sicht nur sachlich unmissverständliche Aussagen getroffen werden. Nicht, das M. Gerner noch zu dem Schluss kommt, dass die KUKA Roboter grundsätzlich schwere Sicherheitsmängel aufweisen.8|

    Nun ja, es soll ja für den privargebrauch sein. Was soll denn beim robocoaster grundlegend anders sein?? Woher kommen denn die ganzen Sicherheitsbedenken? Der Roboter macht doch nur das was er programmseitig bekommt und mann kann noch zusätzlich einen guten not aus verbauen. Oder zusätzlich noch mit zb 2 sick bereichsscannern eine zone vordefinierten, wo dann ein zusätzlicher not aus ausgelöst wird wenn der Arm die zone verlässt.

    Moin,

    Deine Zeilen verdeutlichen leider schon Dein grundsätzliches Sicherheitsproblem. Ein Sickscanner ist nicht dafür da, dass der Roboter seinen Arbeitsraum verlässt, sondern dass niemand seinen Arbeitsraum verletzt. Sowohl ein Sickscanner als auch ein Notaustaster sind nur noch das letzte Mittel um den Roboter mit möglichst geringem (sprich Personen-) Schaden zum Stehen zu bringen. Daher gibt es bei KUKA z.B. SafeRobot (KRC2) als auch Safeoperation (ab KRC4) welche auf Roboterseite überwachen, wohin sich der Roboter aus Sicht der Sicherheitssteuerung bewegt und ob das so i.O. ist. Im Fehlerfall ergreift dann die Sicherheitssteuerung die Initiative und bringt das Gerät zum Stehen. Das hat nichts mit dem Ablaufprogramm zu tun. (Gehe nicht davon aus, dass der Roboter dahin fährt, wo Du es für den Moment erwartest. Das haben schon einige aufgrund persönlichem Irrtums mit dem Leben bezahlt.) Die Konfiguration der Sicherheitseinstellungen bedingt vorangegangene Gefährdungsbeurteilung nach den einschlägigen Vorschriften. (Abstände, Geschwindigkeiten, bauliche Gegebenheiten ....)

    Zur Manipulator-Hardware ist zu sagen, dass die für die Sonderanwendungen Robocoaster usw. verwendeten Maschinen aus selektierten und besonders geprüften Bauteilen zusammengeschraubt werden. Selbstredend sind die Steuerungen mit den Safe(Operation)optionen ausgerüstet.

    Privat kannst Du machen , was Du willst. Aber das wurde ja schon von Herrmann erwähnt. Ich wollte nur noch einmal auf die Gesamtgefährung hinweisen. INDUSTRIEROBOTER sind eben kein Spielzeug und es wäre unverzeihlich, wenn in diesem Forum Tipps zu automatisierten Suizid gemacht würden.

    Grüße

    Moin,

    die damals verwendeten Schläuche gibt es meines Wissens nicht mehr.

    Die neueren haben allerdings aber eine andere Kontur. womit es u.U. zu Problemen mit den Befestigungsschellen kommen könnte.

    So wie der Schlauch aussieht, würde ich die Maschine nicht weiterbetreiben. Die Bruchkanten können die Leitungen beschädigen. Wenn das passiert... $$$

    Hi, Problem bei Safety Integrated ist dass in der NC und im der PLC das Sicherheitsprogramm laufen. Ausgänge (Outseps) werden dort gesetzt. Hier ist manchmal eine kleine Differenz. Haben dies per Analyzer festgestellt. Kuka kommt damit nicht klar.

    Bei einer F-CPU läuft alles in dieser sicheren PLC.

    Hi,

    danke für die Erklärung. Mir war durchgerutscht ,dass das die PLC auf ner NC läuft.

    Hi, dies ist ein Problem von Safety Integrated. PLC / NC schalten nicht 100% synchron. Deshalb wird sporadisch kurzzeitig kein Tool an Kuka gesendet.

    Wir haben deswegen extra eine F-PLC eingesetzt.


    Grüße

    Äh,

    Safe geht doch nur über die F-CPU? Die E/A liegen nicht im Standardbereich.

    Zum Ablauf selbst: Ist es notwendig, das Safe-Tool umzuschalten? Ist die Störkontur so ungünstig, dass man damit nicht "leer" weiterfahren kann?

    Moin,

    also der Antriebsbus scheint richtig konfiguriert zu sein. In beiden Projekten (Projekt 2 und die Kopie) ist der Antriebsbus gleich (und vmtl richtig), auch sind die Zusatzachsen mit drin.

    Offensichtlich ist die $machine.dat fehlerhaft.

    Jetzt wird es tricky. Die KSS 8.2.19 erlaubt nur über ein Umweg das Konfigurieren der Zusatzachsen. Normalerweise werden die MADA über das Kopieren auf der HMI eingefügt. Ein komplettes Erzeugen der MADA aus WOV heraus ist erst ab 8.3.x möglich.

    Mir fällt jetzt nur nicht 100% ein, wie das richtig ging...

    Folgender Versuch: Minimaler Aufwand

    ! Am besten jetzt mal die Festplatte komplett sichern (Image ;) ) !

    1) Mache eine Kopie des aktuellen Projektes und aktiviere diese.

    2) Kopiere über die Oberfläche des Smartpads die Maschinendaten für den KR180 R2500 extra.

    3) Lade das kopierte Projekt mit Workvisual herunter.

    4) Entferne die Zusatzachsen.

    5) Entferne den Roboter und füge ihn wieder hinzu.

    6) Speichere das Projekt.

    7) Deploye das Projekt.

    8) Füge die Zusatzachsen wieder hinzu.

    9) Speichere das Projekt.

    10) Deploye das Projekt.

    11) Übertrage das Projekt auf die Steuerung und aktiviere es.

    12) Bestätige die Änderungen in der Sicherheitssteuerung.

    13) Neustart mir Daten neu einlesen.

    Viel Erfolg.

    Moin!

    Bitte gehe mal in die Anzeige der "Variablen einzeln"

    Dort lasse Dir mal nach einander zwei Varaiblen anzeigen und mache ein Screenshot von der Anzeige.

    1) $robtrafo[]

    2) $trafoname[]

    Dann poste bitte mal ein Bild vom Typenschild des Manipulators.

    Moin,

    da ein X11 vorhanden ist, kann der Hardwarestand nicht VW sein, zumindest keine reinrassige. Da der Schlüsselschalter 4 Stellungen hat, kann es nicht VW sein. Der Softwarestand ist auch nicht VW. Es handelt sich also um eine "astreine" KRC. Ich fürchte mittlerweile auch, dass das KCP /( oder dessen Leitung ) defekt ist.

    Kontrolliert doch bitte mal am X19 (KCP Anschluss am Schrank) , ob sich nicht ein paar Pins in dem runden Buchsengehäuse nach hinten geschoben haben. Müßte man eigentlich sehr gut von der Schrankinnenseite aus sehen. Ebenso auf der Steckergegenseite.


    Nachtrag_ Bitte poste mal die Liste der installierten Optionen. Dieses Plugin "Autoex" sagt mir auch nichts,,,

    Moin,

    Der Profibus hat nichts mit dem Problem zu tun. Die Sicherheitsschnittstelle X11 ist von aussen und nach aussen einfach als dumme , potentialfreie E/A Baugruppe zu betrachten. Allerdings zweikanalig. Da Du schreibst, dass die Versorgungsspannung dauerhaft gebrückt ist, aber auf den Bildern immer noch ungültige BA gemeldet wird, tippe ich mal auf ein Verdrahtungsproblem.

    Vorweg messe aber noch die Versorgungsspannung an den Stiften 88 / 89. Überprüfe alle Sicherungen auf dem ESC Board.

    Achso: Unten auf dem ESC Board befindet sich ein kleiner Microtaster. Den müßtest Du nach dem Wiederverbinden der X11 auf jedenfall einmal drücken, um das ESC Board zu resetten!

    evtl. Querschluss der beiden Kanäle ......

    Möglich, dann aber nur im Bedienerschutz, weil der nur bei Automatik eine Rolle spielt. Wobei ich aber wetten könnte, dass ein Querschluss (in diesem Fall bei dauerhaften Brücken am BS) schon vorher alle Testausgänge querschliesst. Die Ausgänge , also je A und B sind meines Wissens nach GALVANISCH verbunden.

    Moin.

    In der Aufzählung fehlten die Brücken für die Betriebsspannungsversorgung (welche auf dem Schaltbild von SJX zu sehen sind). Wenn die Stifte 88 und 89 nicht mit einer 24V Spannung versorgt werden, ist der Fehler "Ungültige Betriebsart" eine logische Folge.

    Moin.

    Kurze Aufhellung noch von mir:

    init/Erhard_pcst_1.Ldb enthält die Profibuskonfiguration Masterkreis, also wo der Roboter der Master ist. Was da drin steht, kann keiner sagen. (Ausser Erhardt!? ;)) Zurückwandeln in irgendetwas geht nicht. Da brauchst Du die originale Projektierung aus dem SIEMENS NCM- oder SIMATIC-manager. Die kannst Du dann bearbeiten und eine neue *.ldb erzeugen. Die iosys.ini ist die Verschaltung der projektierten (Profi)busteilnehmer auf die E/A der Robotersteuerung.

    Moin,

    Du hast die Maschinendaten VERSCHOBEN ????

    Die Maschinendaten bitte über die Roboteroberfläche vom LW D in den MADA-Ordner kopieren. Danach Neustart (Kaltstart) der Steuerung durchführen.

    Nebenher: Alle Manipulationen an / mit Dateien, die in der Roboteroberfläche im Pfad R1/ liegen NIEMALS über die Windowsebene vornehmen. Das was Du nämlich vermeintlich auf der Oberfläche siehst, ist nicht der Ordner direkt auf der Festplatte sondern eine Kopie der Daten im RAM des Echtzeitbetriebssystems.

    Moin.

    Wenn das so ist, vermute ich mal, dass in der anderen Anlage immer knapp am Schutzraum vorbeigfahren wird. Ein Stück weit spielt nach meinem Kenntnsisstand die Orientierung der Handachsen eine Rolle. Die vermeintlichen Kugeln in der Sicherheitskonfiguration sind eigentlich Würfel, deren Kantenlängen dem Durchmesser der Kugel entsprechen. Soll heissen, die Kugel hat zusätzliche (nicht sichtbare) Störkonturen, die auch ausgewertet werden.

    Mal als zweidimensionale Skizze:

    kugel.png

    Ich bin mir nicht mehr sicher, inwiefern die Würfel ausgerichtet sind. Ich kann mir aber vorstellen, dass beim seitlichen Über-/Unterfahren eines Schutzbereichs die Überwachung zuschlagen kann.

    Moin,

    raus läuft das Öl alleine. ;) Wenn die Achse richtig steht.

    Rein geht es auch , wie Martin Huber das beschreibt. Nur sollte die Drehzahl soweit regelbar sein, dass beim Befüllen es so langsam läuft , dass auch die Luft aus dem Getriebe entweichen kann. Andernfalls dauert das Putzen der Anlage hinterher länger als das Füllen. [Erfahrungswert!]

    Im Normalfall werden die Getriebe steigend befüllt. An der Öffnung der Ablassschraube wird der Schlauch mit einem konischen Kunststoffstutzen angedrückt und dann das Öl reingedrückt. Die Luft entweicht nach oben.

    Moin,

    Symantec Ghost geht auch.

    Unbedingt vor dem Herunterfahren immer 'Kaltstart mit Daten neu einlesen' anwählen.

    Der Klon läuft so später beim ersten Hochlauf 'frisch' hoch. Abgesehen davon spart das fehlende 'HibernateSpeicherFile' Platz im Image.

    Die KUKA RecoverySticks sind eigentlich für die (V)KRC4 recht cool, weil man eben nicht die HDD ausbauen und durch die Gegend tragen muss, haben aber eben ihren recht hohen Preis.

    Für die KRC2 sind diese aber nur bedingt verwendbar (Mainboard- und speicherabhängig) und für die KRC1 gar nicht. Insofern ist bei verschiedenen Gerätegenerationen die externe Variante angesagt, da man ohnehin Adapter und Software braucht.

    Moin.

    Genauso ist das . Allerdings ist dann bei der KRC2 zu beachten, dass das Servomodul (= 'KSD' ) auch vom Bus genommen werden muss. Der Antriebsbus findet sonst beim Init das in den MADA nicht vorhandene Modul "elektrisch" am Bus und kommt nicht klar. Also einfach die Busverbindung austecken, Das KSD für die A7 befindet sich oben links im Schaltschrank und muss indem Fall das letzte am Antriebsbus sein. Einfach den "Netzwerkstecker" aus dem vorherigen Ausgang am KSD A6 ausstecken. Schrank einschalten und über weniger Fehlermeldungen freuen!

    Grüße