Posts by Hermann

    Denke du bist da auf der falschen Fährte. Der Bootloader scheint doch io zu sein. Dir fehlt nur ein Betriebssystem. Wenn ich. Mich recht erinnere kannst du das mit Robinstall erstellen (Boot Disketten, oder per Netzwerk installieren) , sofern du den Key und die passende Robware Version hast.

    Ja, in so einem Fall sollte man wirklich nicht einen fast zwei Jahre toten Thread wieder ausgraben, sondern einen neuen erstellen. Ist ja nicht mal die selbe Steuerungsgeneration.


    ... da gewisse Punkte nahe beieinander liegen (1,2,3,... mm) ...

    Das ist häufig ein Problem, da gibt's fast immer Probleme mit der Geschwindigkeit. Ist immer ein Rumgeschraube an den ganzen schon genannten Parametern und Punktekoordinaten. Weiss jetzt nicht, ob auch $vel.ori1, $vel.ori2, $acc.ori1 und $acc.ori2 genannt wurden.


    Ein kurzer Film würde da sicherlich helfen können.

    Da solltest vielleicht noch die ungefähre Gegend angeben, in der der Roboter steht. Macht vielleicht Sinn, wenn der Crashkurs am eigenen Roboter stattfindet, und keine allzu langen Fahrzeiten anfallen.


    Und es kommt wie immer von allen Seiten die Warnung:

    Roboter sind gefährlich, und kein Spielzeug, also Vorsicht !

    Meinst du hier einmal die KRC als Controller und einmal der KRC als Device die dann beide die gleiche (eine) IP-Adresse haben?

    Ist das jetzt nicht schon zwei mal genau so dargestellt? Wüsste nicht wie man das noch klarer darstellen sollte.

    ... Ist es möglich über eine physikalische KLI-Schnittstelle zwei verschiedene Subnetze laufen zu lassen? ...

    Ja, das hilft aber nicht, denn soweit ich weiss muss der Profinet Controller und das Device (heisst bei Profinet politisch korrekt nicht Master/Slave ;)) die selbe IP-Adresse haben. Lässt sich in der Profinetkonfiguration schon gar nicht anders eintragen. Macht doch auch keinen Sinn da unbedingt unterschiedliche Subnetze zu verwenden.

    Ändert nix daran, dass der Roboter eher so wie bei meinem Beispiel auf der KL montiert ist. In welche Richtung E1 da positiv ist weiß ich nicht mehr. Daher dürften die Parameter auf alle Fälle falsch sein. Aber konfiguriere es doch mal im WoV einfach selber korrekt.

    Vorher aber auf alle Fälle
    den aktuellen Stand korrekt sichern und aufbewahren.

    Wo auch immer 'vorne' ist ;).

    Ich hab' hier einen, der sieht so aus:


    hat die Daten:

    Code
    $ET1_NAME[]="KL4000T_KR600_40 2"
    FRAME $ET1_TA1KR={X 0.0,Y 0.0,Z 689.000,A 0.0,B -90.0000,C 0.0} ;FRAME ZWISCHEN A1 UND FUSSPUNKT DER KIN IN TRAFO ET1
    FRAME $ET1_TA2A1={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN A2 UND A1
    FRAME $ET1_TA3A2={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN A3 UND A2
    FRAME $ET1_TFLA3={X 0.0,Y 0.0,Z 0.0,A -90.0000,B 270.000,C -90.0000} ;ZWISCHEN FL UND A3
    FRAME $ET1_TPINFL={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN MESSPUNKT UND FL

    und funktioniert wie er soll.

    Kann ja auch sein, dass der Roboter beim ersten Start eine SAK-Fahrt macht, weil er sich beim Öffnen des Bedienerschutz bewegt hat. Dann beim zweiten Start läuft das Programm wieder an.

    Starten des Programms wenn Roboter nicht auf der Bahn ist sollte man vermeiden, da gibt es öfter mal unschöne Zwischenfälle mit verbogenem Equipment :(

    Da gibt es vermutlich einige mögliche Ursachen, die Sache mit der öffentlichen IP-Adresse für 50,- gehört m.M. nicht dazu.

    Beim mir war es so was ähnliches, aber zwischen Kabel-LAN und WLAN. Da hatte sich ein HP-Dienst (sowas wie "LanWlanSwitchingService") herausgenommen, bei eingestecktem LAN Kabel das WLAN auszuschalten. Nach deaktivieren dieses Dienstes klappt auch der parallele Betrieb von LAN und WLAN. Vielleicht findest ja da was ähnliches.

    Wenn der Robi in EXT steht dann kann der Anwahlbutton nicht in Automatik funktionieren, weil höchste Betriebsart T1 ist. Das sollte doch ausreichen um eine doppelte Anwahl zu verhindern?

    Im Prinzip vermutlich ja.

    Ist aber doch wurscht, wenn es nicht zum Daimler-Zeugs hinzugefrickelt werden soll. Für einen Test einfach die Daimler-Aufrufe im SPS.SUB auskommentieren. Halt nicht vergessen es wieder rückgängig zu machen.

    Jetzt kommt die Frage!!! Es ist auch vollkommen egal wo der Robi steht. Es ist eine Allgemeine Frage.

    Da bin anderer Meinung. Das ist eben nicht egal, wenn es kein Roboter von der Stange ist, mit Kuka Standard Konfiguration, sondern ein bereits inbetriebgenommener Roboter mit essentiellen Änderungen an nahezu allen Ecken und Enden der Standard Anwenderprogramme.


    In einem 'jungfräulichen' Roboter von KUKA frisch ausgeliefert:

    Setze eine globale Variable über den Button auf TRUE (nenne wir sie mal bStart)

    Dann im SPS.sub innerhalb des Loop / Endloop:

    Code
    IF bStart THEN
    CWRITE($CMD,STAT,MODE,"RUN /R1/Program/UP_xxx_yyy()")
    bStart=false
    ENDIF

    Falls Du das auf dem Roboter bei Daimler machst kann es zu Problemen kommen, denn die bereits bestehende Logik für die Programmanwahl kann da zwischenfunken. Bringt halt nix, wenn an zwei verschiedenen Stellen die Programmanwahl erfolgt.


    Edit:

    Bin nicht unbedingt der Oberverfechter von Standards, aber die grossen Konzerne haben schon Ihre Gründe einen Standard vorzuschreiben. Wenn da jeder macht was er will, dann haben die Betreiber und Instandhalter es sauschwer die Anlagen am Laufen zu halten. Also sollte man sich schon an den Standard halten, soweit es irgendwie geht, wenn es auch manchmal schwerfällt. Jm2c.

    Dass das ein Roboter nach einem Daimler Standard ist, hättest ja gleich sagen können.

    Die Programmanwahl wird genau in dem Unterprogramm DAI_SYSTEM_SPS() gemacht.


    Wenn der Roboter zu Daimler gehen soll, dann sollte man sich auch deren Standard halten, je nach Abnehmer bekommt man sonst massive Probleme und darf von vorne anfangen.


    Wenn der Roboter nicht zu Daimler (oder einer angegliederten Firma, die sich auch an den Standard hält) geht, dann wirf das ganze Daimler Zeug raus, lohnt sich nicht unbedingt sich da einzuarbeiten, zumal da auch ein passendes SPS-Programm mit großem Siemens HMI-Display dazugehört.

    IF $MODE_OP==#EX THEN

    CWRITE($CMD,STAT,MODE,"RUN /R1/Program/Unterprogramme/XXX_XXX1()")

    ENDIF

    Auch hier vermisse ich den OneShot. Also das Verhindern des dauerhaften Auslösens des CWRITE. So wie es hier aussieht wird der Befehl in der Betriebsart EXT ständig in ca 24ms Abständen ausgeführt, das kann eigentlich auch nicht wirklich funktionieren. Plädiere auch dafür mal das komplette SPS.SUB hier zu zeigen, da muss noch mehr faul sein. Das Anwählen von anderen Programmen funktioniert normalerweise tadellos.

    Evtl. sollte Du da noch ein 'cancel' vorausschicken, weil schon ein Programm angewählt ist.

    Ausserdem solltest nach dem 'run' das flag zurücksetzen, damit der Befehl nur Ein einziges Mal ausgeführt wird, ansonsten gibt es eh seltsame Effekte.

    Könnte es sein, dass die Kondensatoren leer waren und erst aufgeladen werden mussten?

    Die sind nach dem Ausschalten nach maximal 10 Minuten immer leer. Das ist nicht die Ursache.


    Weiter habe ich das Ladegerät für meinen Stapler an der gleichen Leitung angeschlossen wie der Roboter und es lief, als ich den Roboter eingeschaltet habe. Vielleicht gibt ja das Ladegerät irgendetwas ins Netz zurück!?!?

    Da sollte nix zurückgegeben werden. Auch das kann man ausschließen.


    Trafo falsch angeschlossen?