Beiträge von stefanM

    Ja, richtig verdreht und verschiebt der Doppelpunkt-Operator schon.
    Es kommt nur drauf an, was man erwartet, was rauskommt - auf jeden Fall keien einfache Koordinaten-Addition.
    Stichwort Transfomationsmatrix und Euler Winkel - einfach mal googeln.


    Gruss Stefan

    Hallo,


    der Chipsatz auf dem Mainbord ist zu alt.
    Selbts ein Bios Update hilft da nicht.
    Versuch mal einen 5 Jahre alten PC vom USB-Stick zu booten - tut 100% auch nicht.


    Gruss Stefan

    Hallo,


    automatik extern ist schon richtig.
    Von der Geschichte mit dem selbstaendigen einschalten wuerde ich aber die Finger lassen.
    Das Einschalten und Programmstart ist da nicht das Problem - aber wie bekommt man die Kiste wieder angehalten?
    Auch mit dem Hauptschalter???


    Zumindest eine Start/Stoptaster (mit Halt nach Taktedende Funktion) wuerde ich vorsehen.
    Wie mann das mit dem SPS-sub und Autonmatik Extern loessen kann (Antriebe ein, meldungen quitieren, Programmstart) wurde hier im Forum schon ofter diskutiert.


    Gruss Stefan

    Hallo,


    der Crash hat mit dem CONTINUE gar nichts zu tun.
    Das Signal darf auch nicht im Vorlauf anstehen - sonst waere die Verrieglung ja zeitkritisch.
    Hast du das Signal diFreigabeHolen nach dem Crash geprueft?


    Ich sehe keine Verriegelug der Roboter gegenseitig.
    Wenn eine PLC im Spiel ist, muesste dort sowas programmiert sein:


    U "diRob2InWorkSpace"
    U "diRob1WerkstPosOk"
    = "doRob1FreigabeHolen"


    Gruss Stefan

    Hallo,


    Wenn die Maschinedaten falsch (falscher Typ) sind, kann auch die z-Richtung nicht stimmen. Zudem wuerde bei einer Fahrt in X, Y oder Z keine Gerade rauskommen.


    Das die Koordinatenrichtung von Z stimmt irritiert mich dann doch sehr.


    Gruss Stefan

    Hallo,


    ich kenne mich mit Denso nicht aus.
    Prinzipiell gibt es eine Ungenauigkeit bim Mathematischen Modell - wie hier schon beschrieben.


    Hier werden Encoder verwendet?
    Dann kann es auch an der Feedback Kalibrierung liegen. Wenn z.B. ein Motor ausgebaut und wieder eingebaut wird, muss ein Offset zwischen Encoder Nullpunkt und mechanischem Nullpunkt neu festgelegt werden.


    Gruss Stefan

    Hallo,


    Sindelfingen und Bremen habe ich keine Ahnung - Neckartal schon.


    Daimler ist ein Problem. Da koennen die "Programmierrichtlinien" links vom Gang von denen rechts so unterschiedlich sein, wie die die Farbe der Schaltschraenke.


    Ich hab seit ca. vier Jahren nix mehr mit denem am Hut, aber allgemeine Richtlinen gab es da nie.
    Am bessten du setzt dich mit dem zustaendigen Instandhaltungschef in Verbindung - mit dem hast du sonst spaeter die Groessten Probleme.


    Gruss Stefan

    Hallo,


    fragen ist hier erlaubt.


    @ Roboman:
    Wenn du einen KR1000 schonmal angefasst hast, ist deine Antwort OK.
    Ich hab so einen weder gesehen, noch in Betrieb genommen, bleibe eine qualifizierte Antwort also schuldig (obwohl du vermutlich recht hast).


    @cycflag:
    Man bekommt hier nicht immer die Antworten, die man sich wuenscht. Das Post von Roboman war aber bestimmt kein persoenlicher Angriff. Schulung oder keine Schulung bleibt jedem selber ueberlassen - es geht auch ohne.


    Gruss Stefan

    oder


    Dann nimmts Du halt noch eine zweite Variabe, die erst nach der Auswertung zurueckgesetzt wird.


    PAW.


    am anfang eines programmes muss zwindend ein PTP punkt angefahren werden (Egal ab E6Axis, oder E6Pos), damit die Konfiguration stimmt.
    Wenn der Roboter im Programm von hand von einem Punkt wegbewegt wird, ist die SAK-Fahrt ebenfalls erforderlich.
    SAK bedeutet Rueckpositionieren auf die bahn.


    SAK-Fahr ist also mit jeden Punkt moeglich.


    Sicher bin ich mir da nicht. Aber ich glaube, es ist sogar möglich, am Anfang vom Programm PTP auf einen Als Frame deklarierten Punkt zu fahren. Das wuerde aber das ganze sicherheitskonzept von KUKA ins wacken bringen (genauso wie PTP $pos_act oder PTP $axis_act)


    Gruss Stefan