Posts by EricH

    SJX sehe ich auch so. Trotzdem ist KUKA leider sehr unintuitiv im Vergleich zu zB ABB. Selbst die einfachsten Dinge muss man bei der Hotline nachfragen, weil vieles auch nicht im Handbuch zu finden ist bzw nicht erklärt ist.


    Challenge: Versuch mal eine Programmreferenz bei KUKA Xpert zu finden. Also zB eine Erklärung von PDAT oder INI und stoppe mal die Zeit.


    Dann versuche mal das gleiche bei ABB. (speeddata, zonedata) Wobei sich hier schon fast keine Frage mehr stellt, da man aus dem Name schon rauslesen kann was es ist.

    Hermann Es gibt da auch eine mitgelieferte Distance() Funktion.


    Es bleibt hier das Problem der unendlich vielen möglichen Orientierungen, die dem Roboter melden, dass er in Position ist, auch wenn die Orientierung so ungünstig liegt, dass es einen Crash gibt. Liegt daran, dass der TCP nur auf Translation geprüft wird. Das Risiko, dass dies passiert hält sich jedoch auch in Grenzen.

    Einen Ausgang definierst du in der Systemkonfiguration unter I/O oder E/A abhängig von der eingestellten Sprache.


    Falls du nicht weißt wie das geht, dann würde ich eine Basis Schulung empfehlen.

    Hmm die Fehlermeldung ist ziemlich nichtssagend. Also er will nicht auf den Punkt fahren, weil dieser außer Reichweite ist. Der Punkt selbst hat aber auch die externe Achse berücksichtigt? Punkt wird mit MoveJ angefahren und hat die richtige Configuration?


    Naja wie gesagt auf dem Felxpendant kannst du einstellen aus welcher Sicht die Koordinaten angezeigt werden. In deinem Bild ist es in Werkobjekt Koordinaten. Unter Positionsformat kannst du die Anzeige ändern.




    Das mit dem DO verstehe ich ehrlich gesagt nicht?

    Hab dein Post nicht so gründlich gelesen. Also im Endeffekt meinte ich das, was du schon umgesetzt hast, eleganter wirds wohl nicht mehr werden, schätze ich. Du kannst probieren den Code sauber zu halten, indem du die Traps nach der Bewegungsreihenfolge anordnest, wahrscheinlich hast du das aber auch schon gemacht. Super wäre es, wenn man in der Trap die nächst folgenden Bewegungsbefehle als Parameter hätte, dann könnte man eine allgemeine Trap schreiben, die abhängig der übergebenen Paramer schaltet.

    Mal so am Rande, es lässt sich auch viel Taktzeit einsparen, wenn die Zelle entsprechend konstruiert wurde.


    Eine Optimierung bei Stopp-Punkten bringt eigentlich pro Stopp-Punkt nur ein paar 100 ms ein.


    Zum Thema: Eine Möglichkeit wäre evtl. bei der letztmöglichen Position zum Bremsen ein DO zu schalten und mit der Schaltung dann zu prüfen ob gestoppt wird.

    Was genau meinst du mit Links richtig connected? Meinst du die Armteile eines eigens erstellten Roboters? Die Links sind normalerweise immer richtig. Die Positionen sind natürlich in Realität ein bisschen woanders als vom CAD. Dazu müsstest du die Sachen im CAD entsprechend verschieben, damit es an der Realität angeglichen ist.


    Wenn ich dich richtig verstehe hast du eventuell eine weitere Station erstellt wo kein CAD drin ist. Am einfachsten wäre es, ein Backup von der realen Steuerung zu machen und das dann auf den virtuellen Controller der richtigen Station einzuspielen.

    Zuerst solltest du klären wie genau die Variable aussieht und was sie bedeutet. Danach kannst du zum Beispiel deine Programme per TEST-CASE - Struktur abfahren lassen.


    Wenn du beispielsweise die 6 Seiten eines Würfels variabel abfahren lassen möchtest, dann lässt du den Bediener die Seite wählen, wodurch als Ergebnis eine Zahl von 1-6 entsteht. Das Ergebnis nimmst du dann als Entscheidungsfindung, welches Bewegungsprogramm als nächstes gefahren wird.


    Wie gesagt es hängt ganz davon ab, was genau variabel sein soll.

    Erstmal einen virtuellen Controller erstellen, sowie Robbi positionieren und dann müsste das ganze Programm vom alten Controller auf den neuen drauf kopiert werden und die Systemparameter angepasst werden. Eventuell kannste auch nen Backup laden, aber könnte auch schiefgehen.