Posts by ottosieben

    Moin,

    die Akkus werden nur zum Herunterfahren benötigt.

    Ein paralleles Anklemmen eines Ladegeräts ist deswegen schon nicht notwendig.

    Weiterhin würde ich davon ausgehen, dass ein solches Vorgehen die intern vorhandene Ladeschaltung ein wenig irritiert und eventuell Schäden verursacht.

    Wenn die Akkus im Leerlauf unter 24V bringen , sind diese sehr wahrscheinlich auch hinüber.

    Wie alt sind die denn? Der Wechselintervall beträgt lt. KUKA 24 Monate!

    Also Akkus wechseln oder bestenfalls versuchen, diese vorher extern zu laden. Ein intelligentes Ladegerät zur Beurteilung des Akkuzustandes könnte hilfreich sein. Eine Anschaffung desselben aber nicht, wenn die Akkus regelmäßig erneuert werden.

    Nebenbei erwähnt ist das häufige Herunterfahren der Akkulebensdauer auch eher abträglich, die Maschinen sind für Dauerlauf konzipiert...

    Viel Erfolg

    Technisch gesehen sicher wie oben machbar, Sicherheitstechnisch aber fahrlässig!

    Bewusste Handlung fehlt hier.

    Leute wie Servicetechniker, die nach Störungen Anlage evtl. mal langsam testen wollen, und dies nicht wissen, legst Du gewaltige Eier so. Und ja, ich rede von Erfahrung exakt damit.

    Moin,

    da kann ich nur voll zustimmen. Da ist gefährlich. Wenn zB. nach einer Reparatur an der Anlage , dass muss nicht mal der Roboter selbst gewesen sein, eine Aufnahmeposition zur Kontrolle langsam angefahren werden soll, kann das direkt zum Crash führen. Servicetechniker, welche die zB. zur Wartung oder Störungsbeseitigung an eine ihnen fremde Anlage kommen, werden nicht erst den Programmcode auf solche Situationen untersuchen (können).

    Ich habe es selbst erlebt, dass nach einem Zentralhandtausch der Roboter in eine Spritzgiessform reingeschossen ist, obwohl ich natürlich erstmal nur mit 3% und dem Daumen auf 'Cycle Stop' schauen wollte, ob alles passt. - Erzähl mir bitte in dem Zusammenhang keiner was von Justageprüfung, die alte Zentralhand war hinüber und ob überhaupt eine korrekte (Last)-justage gemacht worden war , wusste sowieso keiner.

    Besser wäre da die Lösung, bei nicht 100% POV an der übergeordneten Anlage eine Meldung abzusetzen und nach 'X' Takten die Anlage in ein sauberes 'Halt nach Taktende' zu versetzen. Der Bediener muss dann schon sehr stumpf sein, wenn er immer wieder nach 'X' Takten die Anlage neu aufstartet.

    Moin ,

    in dem Beitrag steht, dass gleiche Module gegeneinander getauscht werden können. So ist es auch.

    Eine Änderung der Bestückung zieht immer eine Änderung der Konfiguration mit sich.

    Zu Deinem seltsamen Getriebemomentfehler fällt mir jetzt noch etwas ein. Sind die Stecker der Motorenüberleitung (Schrank - Manipulator) fest aufgesteckt und verriegelt?

    Ich hatte schon mal einen Fall ...

    Nun ja, der Achse 4 Motor treibt auch über einen Zahnriemen eine Hohlwelle an. Diese führt nach vorn zur Zentralhand.

    An der Seite bei den Motoren sind schwarze ovale Abdeckkappen, welche man mit einem Schraubendreher leicht rausklispen kann. Da hinein würde ich mal mit einer Taschenlampe schauen. Eventuell hat es den Zahnriemen der A4 zerlegt und dieser wickelt sich jetzt elegant irgendwo ein und blockiert den Motor.

    Moin,

    die mitgelieferte Win95 Version ist auf das System zugeschnitten. Irgend etwas im Nachgang zu deinstallieren ist also nicht zielführend. Beispiel TCP/IP: Die KRC benutzt im Hintergrund FTP , um die Dateihaltung im SharedMemory des VxWorks und der Festplatte zu synchronisieren.

    Fazit: Nichts ändern.

    Grüße

    Mobile plattformen wie KMR Quantec usw nutzen DC/AC Wandler.

    8+ Akkus mit so was machts schon, egal ob Steuerung KRC1, KRC2, KRC4 oder KRC5 ist

    Moin,

    der TO schrieb , er wolle DC-DC Konverter einsetzen.

    Eine DC -> 3~ Konvertierung wäre eine Lösung, welche keine Änderung an der Robotersteuerung notwendig macht. Insofern also die richtige Lösung. Da bin ich voll bei Dir. Ich habe aber auch schon den Akkupack des KMR Quantec gesehen. Das Ding ist eine Hausnummer. Mit einer Bastellösung hat das nichts zu tun.

    Grüße

    ...

    Ich würde Dir folgendes Szenario vorhersagen (obwohl meine Kristallkugel immer noch beim irren Polterer liegt):
    Selbst wenn Du es schaffst, die Servos aus Batterien zu versorgen und die Fehler zu überbrücken: In dem Moment, wo die Bremsen gelüftet werden, klappt der Roboter wie ein Kartenhaus zusammen, dein Umrichter geht in die Leistungsbegrenzung und schaltet ab, die 27 Volt für den PC brechen zusammen und dadurch stirbt Deine Festplatte. ....

    WolfHenk

    Moin,

    ich glaube, Du kannst die Glaskugel als Dauerleihgabe beim Polterer lassen!

    Vor meinem geistigen Auge hatten die Bremsen sogar schon kurz gelöst und der Manipulator ist mit krachendem Geräusch vornüber aus der Garage gefallen...

    Moin,

    warum wohl hat der Roboter eine Drehstromeinspeisung? Es braucht schon Kraft, um die Achsen überhaupt in Position zu halten. Achse 2, 3 zeigen wohin? Nach unten. Wenn die Gravitation abzustellen geht, könnte es klappen.

    Weiterhin funktioniert die Kühlung des Schrankes nur mit Drehstrom.

    Das Powermodul wird auch keine Antriebsfreigabe geben, wenn das Netz nicht anliegt.

    Grüße

    .. Scheint also schon im Ansatz verkehrt zu sein, vom Roboter aus den Greifer steuern zu wollen, wie ich das lese. Würde mich also zurücklehnen und den Projektleiter auf den SPS-Programmierer verweisen.

    Moin,

    genauso sehe ich das auch. Warum sollte die SPS nicht über mxAutomation die physikalischen Ausgänge für den Greifer steuern? Es braucht auf dem Roboter in dem Fall kein Grippertech. Sämtliche Logik liegt bei der SPS.

    Grüße

    Moin,

    mxAutomation ist eine Datenschnittstelle. Das bedeutet, dass die Kommunikation zwischen SPS und Roboter über die Ein/Ausgänge in einer Art 'Protokoll' abläuft. Die E/A werden auf Roboterseite von der SoftSPS (Proconos) benutzt, auf SPS Seite bewerkstelligen dies die mitgelieferten Funktionsbausteine. Diese Funktionsbausteine beinhalten sicher auch eine Abfrage auf "Home" und speichern dieses in eine Datenstruktur des Instanzdatenbausteins für den gekoppelten Roboter. Die einzelnen E/A haben also keine direkte Funktion. Insofern macht eine 'Benamsung' der E/A dieses Schnittstellenbereichs also keinen Sinn.

    Bei Verwendung von mxAuomation bleiben nur wenige freie E/A über. Diese könnte man theoretisch verwenden. Das widerspräche aber dem eigentlichen Konzept von mxAutomation.

    Grüße und viel Erfolg

    Moin,

    wenn denn die Zentrierung passt, liegt das Bauteil richtig. Was kann dann noch sein?

    -> Stimmen die Lastdaten? [[Das Bauteil wiegt 5kg, aber was wiegt der Greifer? Welcher Massenschwerpunkt ergibt sich? Welche dynamischen Einflüsse hat es, mit 1 m² 'Segel'. Was ist das überhaupt für ein Roboter?]]

    -> Wie häufig kommt denn die Kollisionsüberwachung?

    -> In welchem Programmschritt löst diese aus?

    -> Welche Einflussgrössen spielen in diesem Programmschritt eine Rolle?

    Viel Erfolg

    easywork

    Moin,

    hier scheint ein grundlegendes Verständnisproblem vorzuliegen.

    Kollisionsüberwachung sagt, wie schon woodys andeutet, dass der Roboter Momente aufnimmt, welche nicht erwartet werden. Das kann auch mit falschen Lastdaten zusammenhängen.

    Also 'Hausmittel':

    1) Lastdaten kontrollieren

    2) Aufnahmen konstruktiv so gestalten, das Lagefehler minimiert, bestenfalls ausgeschlossen werden

    3) geeignete Sensorik an den Aufnahmen installieren, welche bei Lagefehler den Entnahmeprozeß stoppen

    4) Irgendwelchen Spuk mit dem Roboter machen, welcher die Lagefehler korrigiert.

    Die Aufzählung ist nicht willkürlich sortiert. Ihr liegen folgende Strategien zu Grunde:

    # Der Roboter ist eine dumme Maschine, welche für die Anwendung korrekt konfiguriert werden muss.

    # Jeder Prozess in sich sollte stabil sein, um die Fehlertoleranz für den nächsten Prozess zu minimieren.

    # Jedes einzelne Prozessergebnis muss überwacht werden.

    # Ergebniskorrekturen durch nachfolgende Prozesse kosten TAKTZEIT und damit PERMANENT Geld.

    Viel Erfolg.

    Moin.

    Es ist schon eigenartig, dass der Fehler nach Pausen oder längerem Teachbetrieb auftritt.

    Wird in diesen Zeiträumen der Bedienerschutz geöffnet?

    Ich hatte mal einen Fall , bei dem durch einen Fehler im Ablauf das ESC Board in einen fehlersicheren Zustand wechselte, welcher dann nur noch mit PowerOff zu beseitigen war (auch der RESET auf dem ESC brachte nichts!)

    Dabei geht es um die vorgegebene Signalfolge beim Verriegeln des Bedienerschutzes im Zusammenhang mit Antriebe ein, Move Enable und Störungsquittierung. Ist schon ewig her, deswegen kriege ich das eben nicht mehr richtig zusammen. -> Kernfrage . Wurde in der Richtung was geändert (SPS?)