Beiträge von Programmiersklave

    Das in den geschweiften Klammern ist eine Struktur (in dem Falle wohl Frame). Man kann auf diese Art keine Strukturelemente ersetzen.
    Versuch's so:


    FRAME meinframe
    REAL X_pos


    X_pos=irgendwas
    ...


    meinframe=$NULLFRAME ;Vorbelegung, damit alles 0 wird
    meinframe.x=X_pos
    ...
    Lin Rel meinframe
    ...

    Erfahrungsgemäß gibt es wohl auch "grenzwertige " Kalibrierungen, besonders in den Handachsen. Wenn die Kalibrierdaten bei ABS(6Kommanochwas)[siehe Aufkleber] liegen, besteht wohl die Gefahr, dass man beim Aktualisieren der Umdrehungszähler in die falsche Umdrehung rutscht. In dem Falle hilft es, nicht exakt in der "Kalibrierstellung" zu nullen, sondern die Achse bewusst minimal in die "bessere" Richtung zu verfahren, bevor man auf "aktualisieren" drückt. Welche die bessere Richtung ist, probiert man am Besten einfach aus.


    Garstig sind auch undokumentierte Motorenwechsel in der Vergangenheit....

    "LOOP" ist ja nix als ne Endlosschleife... was man drinnen anstellt, ist egal.
    Besonders schön finde ich es nicht, ich würde die Zusatzbedingung mit in den Switch nehmen, indem ich nicht mehr auf PGNO teste, sondern auf eine eigene Variable, die ich zusammensetze aus PGNO und der Greifernummer oder was auch immer...


    if $IN[94] then
    greifernummer=100
    else
    greifernummer=200
    endif


    meinewahl=greifernummer+PGNO


    switch meinewahl
    case 101
    ;blabala
    case 102
    ...
    case 201
    ;blabla
    case 202
    ...
    default
    ;kein passendes Programm
    endswitch


    Man muss die Cases nicht unbedingt lückenlos durchzählen und sie noch nicht einmal in der "natürlichen" Reihenfolge haben, da der Interpreter alles durchprobiert. Man kann auch mehrere Cases in eine Zeile nehmen (ohne Spaces nach den Komma):
    case 101,102,103


    Nachteil ist obige Eigenschaft: sollte man SEHR viele cases haben und wenig Zeit, ist eine verschachtelte IF-Then-Lösung u. U. besser, weil schneller.

    Ich vermute eher, Kleinstar denkt zu zweidimensional und betrachtet seine BASE-Koordinaten IMMER als XY-Ebene parallel zur XY-Ebene des Roboters. Das muss bei Anfängern erst einmal "klick" machen, ehe sie wirklich begreifen, dass die Orientierungen beliebig sein dürfen.
    Vorschlag an Kleinstar, zur Veranschaulichung: schmeiss irgendwas in die Zelle und darauf eine Platte, kreuz und quer und schräg, und nimm irgendeinen verbogenen Draht als Tool am Flansch. Dann damit auf der Platte ein Base einmessen, und anschließend das Ganze nochmal, aber mit der Platte anders liegend (anders schräg im Raum) und den Draht anders gebogen. Dann geht Dir irgendwann auf, dass Du ALLE 2 * 3 Winkel brauchst.

    You may also declare your own speeddata type variables, speeddata is a structure:
    < dataobject of speeddata >
    < v_tcp of num > (tcp speed in mm/s)
    < v_ori of num > (orientation speed in °/s)
    < v_leax of num > (linear external axes speed)
    < v_reax of num > (rotational external axes speed)


    Example:
    VAR speeddata vslow:=[50,100,5000,1000];
    Var speeddata vfast:=[3000,500,5000,1000];


    moveL pointx, vslow, z1, Tool;
    ....

    Proportional ist ja so 'ne Sache... Leistung ist Drehzahl*Drehmoment, wenn der Asynchronmotor mit 'nem FU Drehzahlstabil gehalten wird, sollten da schon abgreifbare Werte rauskommen. Moderne FUs lassen sich ja ohne Ende parametrieren, auch die wichtigsten Daten sind oft genug analog auslesbar oder sogar über Profibus etc..
    Notfalls muss man sich im Roboterprogramm eine mathematische Funktion programmieren, die Nichtlinearitäten rauskompensiert - wenigstens ungefähr. Habe ich mal gemacht, um den Durchmesser einer großen Polierscheibe während des Polierens rauszufinden bzw. den Arbeitspunkt hinterherzuschieben.


    Viel interessanter fände ich die Strategie, wie nachher der Regelparameter in das laufende Program einfließen soll. Eine Hintergrundtask könnte ja zyklisch die Werte prüfen und irgendwas berechnen, aber wie bremst man den Vorschub? Eigentlich ja sogar rückwirkend, dem besch. Satzvorlauf bei ABB sei dank... VelSet geht nur in Bewegungstasks, und mit Interrupts könnte man die Bewegung stoppen und neu ansetzen, aber nicht kontinuierlich ändern. Oder man programmiert offline sehr viele, dicht beieinanderliegende Punkte und holt sich die Geschwindigkeit für den nächsten Punkt aus einer Variablen... der Bediener wird sich bedanken, wenn er mal was nachteachen will.


    Vielleicht meinen wir bezgl. des ForceControl-Experiments dieselbe Firma und denselben Versuch :pfeif:

    ForceControl (wenn wir jetzt das gleiche Dings meinen) enthält auch eine Hardware (die Kraftmeßdose am Flansch) und funktioniert suboptimal, wenn der Roboter ein rotierendes Werkzeug führt. Genau für so eine Anwendung hat man das bei uns mal ausprobiert - es erwies sich leider in der Praxis als untauglich. Der Robbi fuhr sonstwo hin.


    Den Ansatz von Michatronik, die Leistungsaufnahme des Motors als Stellgröße zu verwenden, finde ich deutlich erfolgversprechender.

    Hi,


    kommt ja auf den Radius an. Wenn z. B. an der Stelle, an welcher sich der "Buckel" aus der Fläche erhebt, ein Radius von 5 mm ist, und ein Winkel von 45° geändert werden soll, hat er dafür 3,9mm Fahrstrecke. Bei einer Geschwindigkeit von (ich schätze mal Du meinst) 0.2 m/s müsste er also die Gun in 0.02 Sekunden umorientieren... wird schlecht gehen, entspräche einer Umorientierungsgeschwindigkeit von mehr als 2000 °/s, wenn ich nicht gerade falsch rechne.


    Wo ich mal Wasserstrahlschneiden gemacht habe kam es aber auf ein paar Grad nicht an, zumindest, wenn der Strahl parallel zur Schnittebene verdreht wird. Musst Du denn unbedingt umorientieren?


    Umorientierungsgeschwindigkeit etc. kann man auch noch ein bissl rauftunen gegenüber den Werkseinstellungen, aber sooo schnell wird er nicht werden....


    Grüße, Michael

    Das KCP schaltete damals immer sofort ab, mit einem externen Monitor konnte man beobachten, was vor sich ging.
    Hibernation war auch nicht drin, er sicherte seine Achswerte und killte dann Windows 95 durch Abschalten, ohne irgendwas runterzufahren. Sollte die Software-Abschaltung versagen, trat dann nach einiger Zeit ein Zeitrelais in Aktion, wenn man Glück hatte. Wenn nicht, musste man den Stecker am Akku abziehen.....


    direktes reinkopiern ist nicht moeglich; muss innerhalb der der KUA-Oberflaeche passieren (ausser man hat ein spezielles Programm dafuer- z. B. DirLoader).


    Reinkopieren geht nicht, aber ändern, wenn es einmal drin ist.
    Am KCP ein neues Modul mit dem Namen erstellen, danach kann man nach Belieben von ausserhalb überschreiben/ändern, wenn man das Risiko liebt.
    ABER:
    Ob das Echtzeit-System oder das Windows das auch mitbekommt, hängt von mehreren Faktoren ab. Es geht relativ sauber, wenn


      • kein Programm mehr angewählt ist

      • erst NACH dem Abwählen überschrieben wurde

      • unmittelbar nach dem Überschreiben mit dem Editor im Kuka geöffnet wurde

      • man dort irgendwas ändert (Leerzeile einfügen) und dann wieder schließt/speichert


    Sollte man die Reihenfolge nicht einhalten, ergibt sich u. U. der Effekt, dass der Programmzeiger auf dem KCP in der geänderten Version herumspringt, der Robbi aber noch die alte Version abfährt.
    Das Ganze ist also alles andere als empfehlenswert.
    Wenn man auf diese Weise an der $config.dat o.Ä. rumpfuscht, muss man auch den Submit-Interpreter abgewählt haben.


    Nebenbei:
    Auf den Kukas läuft standardmäßig auch ein FTP-Server, soweit ich weiß.