Beiträge von ottosieben

    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?)

    Moin,

    die Lastdaten sind Dynamikparameter fürs Fahren, haben also nichts mit dem TCP zu tun. Prinzipiell sehe das wie Team Rosario .

    Durch die Entlastung entspannt sich die elastische Verformung des Manipulators.

    Weiterhin spielt eventuell auch ein 'ungenaues' Ablegen eine Rolle.

    Genaugenommen müßte zum Aufnehmen der selbe Raumpunkt mit den Lastdaten für "leerer Greifer" angefahren werden, da das Werkstück nicht im Greifer ist.

    In jedem Fall würde ich davon ausgehen, dass der Aufnahmepunkt extra zu teachen ist.

    Für VNC wird's wohl keine geben, es gibt aber durchaus Software von Fremdherstellern (z. Bsp. Wiest) mit CPC Zertifikat, wird also keine Fantastillionen kosten ;) .

    Moin,

    damit hast Du sicher nicht Unrecht.

    Nun ist Wiest aber auch durchaus mit KUKA schon lange unterwegs und arbeitet vermutlich auch zu. (TRACC TCP wär so ein Verdachtsfall ;) )

    Auch OrangeApps hat ja Software für KUKA Steuerungen entwickelt, welche natürlich auch zertifiziert ist.

    Bei einem FREMD-Hersteller , dessen Sourcen eventuell nicht offen sind, kann eine Zertifizierung schon etwas aufwändiger sein.

    Wir reden ja hier sogar von VirtualNetworkControl, was nun definitiv ein anderes Level ist, das böse Wort Control steckt ja schon drin. .. :!:

    Tight VNC lässt sich Installieren da das eine .msi ist.

    Allerdings funktioniert das mit dem RDP nicht korrekt. Da wirft es die KCP Verbindung raus und am VNC Viewer muss man ein BN und PW eingeben. Und auch das funktioniert nur wenn der Schlüsselschalter schräg steht…

    Moin,

    dahinter steckt die Sicherheitsanforderung "single point of control'. Die BOF läßt mehrere zeitgleiche Logins nicht zu, was ja auch korrekt ist.

    Ok.


    Der Aufwand scheint also größer zu sein. Gibt es auch eine Software für CPC um ein Zertifikat zu erstellen?

    Moin,

    prinzipiell muss sichergestellt sein, das die zu zertifizierende Software keine Funktionseinschränkungen und keine Gefahr im Sinne der Maschinensicherheit verursacht. Deswegen ist eigentlich der Hersteller die 'Zertifikatsstelle'. Also müßte KUKA die zu verwendenene Software dahingehend prüfen und freigeben, sprich das Zertifikat erstellen. Das macht KUKA mit seinen eigenen Technolgiepakten udgl. auch. Als Endkunde wird man wohl offiziell kaum in den Besitz des 'Zetrifikatgenerators' gelangen. Eine Zertifizierung von Fremdsoftware wird , wenn das KUKA überhaupt anfasst, mehrere Fantastilionnen kosten.

    Moin,

    wenn CPC drauf ist, so muss muss es für die gewünschte Anwendung ein Zertifikat (*.appcert) geben, andernfalls wird die Anwendung geblockt. Das ist meines Wissens grundsätzlich der Fall, womit es zu diesem speziellen Fall keine Lösung gibt.

    CPC läßt sich nicht ohne weiteres deinstallieren.

    Alternativ könnte man das System komplett neu aufsetzen und CPC dabei weglassen. Im Anschluss das Projekt wieder ohne CPC deployen und einspielen.