Beiträge von Programmiersklave

    am meisten Zeit verschlang das Teachen der Punkte an der Leimdüse entlang. ... Für jedes Teil musste ich um die 20 Punkte teachen.

    Das Teil hat 8 Ecken, und dann noch ein bisschen drumherum. Wie lange braucht man, um 20 Punkte zu teachen? Ca. 10 Minuten? Da biste doch fertig, bevor Windows mit RS hochgefahren ist....

    Ich glaub', der Kollege HeavyRobot hat'n anderes Problem, was ich ungefähr so einschätze:


    - die SPS wollte eigentlich nur wissen, ob auf dem Stapel noch Teile liegen und kriegt den Wert des Sensors, aber nicht der Robbi

    - die SPS weiß allein, was für Teile da liegen, und positioniert den Robbi indirekt oder direkt

    - jetzt stellt einer fest, dass die Stapel nicht gleich auf dem Transport ankommen (das wird grundsätzlich immer erst hinterher festgestellt, ist so eine Art Gesetz) und will mit dem Robbi auf beschriebene Weise suchen

    - und statt den Robbi jetzt den Interrupt fahren zu lassen, will die SPS es machen

    - und der Kollege will jetzt während der Fahrt kontinuierlich die Position rausschicken, um der SPS diese Aktion zu ermöglichen.


    Und das - sollte es denn die Frage gewesen sein - wird so schlecht, dass ich gar nicht erst anfangen will, darüber nachzudenken.


    Ich rate dringend: lass Dir das Signal vom Sensor durchschleifen und mach die Suchfahrt mit dem Roboter. Und nur mit dem Roboter.

    Das würde ich gar nicht anders versuchen als in zwei Schritten, ich kann mich nicht erinnern, beim Rückgabewert einer Funktion unmittelbar auf eine Teilkomponente zugegriffen zu haben. Zum Debuggen ist es eh besser:


    Code
    var pose wo_frame_kompl
    ...
    wo_frame_kompl:=PoseMult(WO_Grundplatte.uframe,WO_Grundplatte.oframe);
    ...
    ...
    to_R1_Spindel1.tframe.rot:=wo_frame_kompl.rot;
    ... 

    Alternativ, noch einfacher - startest gleich mit der kompl. WobJ-pose und überschreibst trans anschließend:

    Code
    ...
    to_R1_Spindel1.tframe:=PoseMult(WO_Grundplatte.uframe,WO_Grundplatte.oframe);
    to_R1_Spindel1.tframe.trans:=p_Spindel1.trans;

    Wahrscheinlich willst Du vom WObj nur die Orientierung, denn Du fährst den Messpunkt in WObj0 an. Wenn nur in einem was drin steht (uframe ODER oframe) sollte es reichen, "rot" rauszukopieren. Wenn in beiden was drinsteht (oder auch wenn nur in einem was drinsteht) dann einmal mit PoseMult zusammenrechnen und aus dem Ergebnis das "rot" kopieren.


    Der entstandene Frame ("pose") ist in beiden gleich, egal ob tool oder wobj. Bei WObj ist's halt blöd, dass immer zwei Frames drin sind.

    Was mir gerade noch einfällt: manche Roboter (besonders wenn sie neu und groß sind) haben einen signifikanten Stick-Slip-Effekt (3 mm wäre allerdings extrem viel). In dem Fall würde es helfen, die Einlegeposition - falls möglich - um einen kleinen Betrag zu überfahren, um dann noch vor dem Spannen die Bewegungsrichtung zu wechseln und erst auf dem Rückweg anzuhalten und zu spannen. Bei der Fortsetzung der Ausfahrbewegung gäbe es dann diesen Versatz nicht mehr.

    Den Punkt bei gespanntem Werkstück zu teachen, hat die selbe Verformung zur Folge, wie das Spannen. Einen separaten Aufnahme/Ablegepunkt zu teachen ist auch keine Option, da das Spannen/Entspannen immer in gegriffenem Zustand erfolgen muss. Was ich absolut nicht verstehe ist, dass der geteachte Punkt zum Ablegen passt, bis das Teil gespannt ist. Beim Herausfahren jedoch dann auf einmal die Roboterposition um ca. 3mm verschoben ist Der Roboter behält dann auch diese Verschiebung bei.

    1.) Wenn die Schwerkraft dran zieht, verbiegt es sich entsprechend. Wenn sie nicht mehr dran zieht, schnappt es zurück, das entspricht vollkommen der Physik, ob das nun ein Baum ist oder ein Roboter.

    Die entsprechende Elastizität ist drin, man braucht ja nur bei eingefallenen Bremsen gegen den Flansch treten - die Schwingung ist deutlich sichtbar.

    2.) Die Lastdaten sind nicht für eine Positionskompensation vorgesehen. Die einzelnen Achsen fahren auf die errechneten Winkel im Vergleich Lageistwert zu Lagesollwert, und rechnen erst einmal nichts dabei oder weg. Der Haltestrom wird automatisch größer, wenn ein größeres Drehmoment benötigt wird, aber es wird ja nur bis zum Sollwert geregelt und nicht darüber hinaus.


    Wenn Du weißt, dass es drei Millimeter sind, dann kannst Du sie ja ins Programm einbauen.

    Für ausnehmend tricky Fälle gibt es noch die Möglichkeit, den Manipulator ein wenig "weich" zu schalten. Man könnte vor dem Öffnen des Greifers 3mm "weich" nach unten drücken. Oder auf der Position bleiben, aber so nachgiebig, dass der Greifer nicht verkeilt.

    Wenn man das noch weiter treibt, kann man auch das "Durchhängen" ohne Last auf dieselbe Position bringen wie "straff mit Last". Das wäre aber von hinten durch die Brust ins Knie und hat eigentlich keinen Sinn, verglichen mit einer "richtigen" Positionskompensation.

    Ich kann aus Projektdaten spontan rekonstruieren, dass ich mit Sicherheit mal eine 8.2.20 auf XPe V3.0.1 Build 19 mit Ultravnc 1.1.8 hatte und das im Grunde lief, aber sich später dann die komische Eigenschaft entwickelte, dass die Benutzerdialoge auf dem Client nicht mehr angezeigt wurden.

    Andererseits bin ich ziemlich sicher, dass bei uns aus Gründen persönlicher Faulheit eigentlich immer als erstes ein VNC Server installiert wurde, von den ersten 4ern an. CPC hatten wir nie.

    Entschuldige aber es zwingt dich doch niemand zu irgendetwas!

    Schon korrekt.


    Aber ich weiß ja vorher nicht unbedingt, ob der Code von einem verzweifelten Programmierer stammt, der Druck von oben bekommt und dem man helfen will. In dem Fall hängt man sich vielleicht rein, kopiert Code der Lesbarkeit halber in seinen eigenen Editor, sucht nach eigenen Projektdaten, wie man es mal selbst realisiert hat, vergleicht zweimal, dass man bloß keinen Mist postet, usw. usf..


    Hat man all das getan und erfährt dann, dass der fragliche Code von einer Labermaschine produziert wurde, wird man sich verarscht fühlen.


    Ich hab' kein Problem damit, wenn solche Tools fachgerecht benutzt werden, ich verfolge selbst aufmerksam die Technik dahinter, hab'n Huggingface-Account, war von ELIZA fasziniert und hab schon vor >35 Jahren auf 'nem Sinclair plausibel klingende Zufallstexte produziert. Nur selber lesen will ich den Quark nirgends.


    Also schreib's bitte in den Titel oder gleich in die Witze-Rubrik, dann fällt es unter optionales Entertainment.

    Nein, bitte nicht berichten.


    Die Grenze ist überschritten, wenn ich damit anfangen soll, von einem Textgenerator erzeugten Text zu lesen. Gar Programme anzusehen. Die Chat-Modelle mögen sich mit ihresgleichen unterhalten, aber nicht mit mir.


    Und noch einmal einen Level drüber sind Berichte über den Auswurf von Texterzeugern.


    Wir müssen mit dem Schiet hier unseren Unterhalt verdienen, da wär's einfach schade um die Lebenszeit.

    Es geht eigentlich um den Punkt P28, da muss Achse 4 und Achse 6 "gegeneinander je um 180 Grad" drehen, da ist die Geschwindigkeit einfach zu hoch (Geschwindigkeitsüberschreitung A4),

    Robot muss von einer Seite angewinkelt, ganz auf die andere Seite auch abgewinkelt fahren

    (ich hoffe, ich hab's verständlich werklärt ;))

    Reicht es wenn ich hier bei P28 auf 0.5m/s oder noch weiter runter gehe?

    ich hab schon den P29 eingefügt, um "abzubremsen", scheint aber nix zu bringen.

    Wenn Du schon 'nen Punkt eingefügt hast: vielleicht ist ja genug Platz, diesen Punkt soweit aus der Bahn zu schieben, dass die Singularität einfach glücklich vermieden wird. Etwas tiefer z. B., oder etwas näher an den Roboter. Geht dadurch auch nicht langsamer.

    Mein Problem ist jedoch, dass ich gar nicht in den Interrupt reinkomme im "normalen Ablauf"..

    Verfahre ich die Bewegung vorher und löse aus, passiert nichts. Springe ich mittels Satzanwahl wieder weiter nach oben, springt der Ablaufzeiger sofort in den Interrupt.

    Ich denke, das ist korrekt so. Wenn Du nicht explizit die laufende Bewegung stoppst, wird die zu Ende gefahren, bevor der Programmzeiger den Erfolg des Einsprungs widerspiegelt. Oder Du die Bewegung eben manuell abbrichst.

    In Deiner ursprünglichen Version ergäbe sich bei unmittelbarer Ausführung ja ohnehin ein Prioritätenproblem, mit dem die Steuerung allein gelassen würde: während die Bewegung zu "XGRP_Pos_TR " noch läuft, soll diese Variable bereits dreimal überschrieben und dreimal gelesen werden (einmal mit $POS_INT, dann zweimal die Berechnung, dann einmal anfahren?!).

    Das liefe auf "während der geplanten Fahrt umentscheiden auf ein anderes Ziel" hinaus. Das will kein Roboter freiwillig.