Posts by Programmiersklave

Red' dem Kunden das aus. Das ist Hexenwerk.

Ernsthaft, es geht, problemlos. Ein Rapid-Programm kann ein anderes Rapid-Programm auf Dateiebene erzeugen oder ändern und dann dieses laden. Hab' ich auch schon probiert. Das kann man sogar verschachteln, kannst einen Rapid-Virus schreiben, den keiner findet und den Robbi durchdrehen lässt.

Und eben da liegt die Gefahr. Wenn Du automatisiert durch den Roboter den Quellcode eines Roboterprogramms änderst, kann alles passieren. Zähler auf Zeile drei? Ach komm. Und was ist mit Backups / Restores? Was, wenn die Schreiboperation fehlschlägt? Wenn im Moment des seriellen Schreibens einer per FTP die Datei austauscht? Was, wenn der Kunde nachher kommt und behauptet, Du hättest Mist programmiert? Kannste nichts mehr beweisen, denn der Robbi hat sich selbst programmiert.

Dann noch: automatisch laden und automatisch speichern ist so'n Ding... wärst nicht der erste, der mühsam geteachte Änderungen durch automatische Dateioperationen ins Nirwana schickt... Verdopplung der Schreibvorgange verdoppelt das Risiko.

Und wer soll wie da reingucken? Derjenige, der die Information wissen will, muss ja dann im Homeverzeichnis die Datei öffnen bzw. downloaden. Die aktuell im Roboter laufende nützt ihm ja nichts, denn die ist ja jetzt geladen. Das heisst, da pfuscht einer im HOME-Verzeichnis in den Bearbeitungsprogrammen rum, nur weil er wissen will, wann was geladen wurde?

Was spricht denn gegen eine vernünftige Log-Datei im CSV-Format, die rollend neu angelegt wird (pro Monat oder so), die kann sich der Kunde dann runterladen und in Excel importieren, wenn er die Neugier hat. Der Informationsgehalt ist größer, die Zugänglichkeit ist einfacher, die Technik ist sicherer.

Um im Programminterpreter dann wieder mit einem Interrupt drauf zu reagieren? Das dauert...

Warum machst Du nicht zwei Interrupts auf dasselbe Signal und schaltest sie bedarfsweise scharf?

Eventuell kriegst Du Deine Positionsbedingung sogar über einen Workspace eingebunden, das dann mit dem Ini in einem $CYCFLAG verknüpft und den "zu tief"-Interrupt mit höherer Prio (kleinere Zahl) deklariert, dann funktioniert das eine sogar innerhalb des anderen.

Bei wechselweisem Einschalten sollte sich die "zu Tief"-Bedingung aber auch problemlos im Suchfahrt-Interrupt auswerten lassen, so dass man während der Suchfahrt auch die Überwachung hat. Reagiert wird ja sowieso auf den Signalwechsel.

Ja, weil der Kuka für jedes Inline-Formular die Speeddaten aus der Datenliste holt. Du bräuchtest ein Programm ohne die Inline-Formulare.

Mit Inline-Formularen wird's sowieso tricky. Ansonsten wäre es kein Problem, eine Variable (vorher) einzulesen und an $VEL.CP zu übergeben.

Quote from WIEKON

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....

0b0000101 etc. ist aber problemlos möglich. Ist eine geläufige Schreibweise für Bit-Operationen und geht bis DNum.

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:

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:

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

Ich hatte mit einem tp-link UE300 am Dell mit dem SinecPNI Programm noch kein Problem bei dieser Aufgabe.

Deutlich schlechter allerdings funktioniert wohl das alte "Primary Setup Tool".

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.

Schreib' dann bitte, ob das funktioniert hat. Und in welche Richtung der Versatz war.

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.

Quote from sonny_

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.

Quote from RoBo_CuRiOsO

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.

In 2D reicht doch ein Layer in einer beliebigen Videoschnitt-Software.

Und wenn es interessant aussehen soll: aus dem Bild kurzerhand ein 3D-Objekt machen und in der virtuellen Zelle platzieren.

Hab ich was übersehen?

Guck mal in der Doku unter Funktionen: NOrient(Rotation)

Deine Werte sind der Steuerung nicht genau genug, aber sie kann es selbst ändern.

Quote from Stoffel67

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.

Quote from YK_Ertl

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.