Posts by Hermann

    Scheint als ob die Kuka Entwickler bei den Splinebewegungen den gleichen Fauxpas begingen wie bei den alten Befehlen.

    Im eigentlichen Bewegungsbefehl innerhalb des Folds wird nicht der Parameter aus dem pdat genommen, sondern direkt der Wert aus der Foldzeile. Sonst müsste da stehen

    Code
    SPTP XAbholPosZuf WITH $VEL_AXIS[1] = SVEL_JOINT(gPPDAT_HND.VEL).... 

    Das ist schon seit über 20 Jahren ein Ärgernis. Man kann die Geschwindigkeiten in Standardbefehlen out of the Box nicht variabel gestalten. Keine Ahnung warum es in der pdat-Struktur eine Komponente für die Geschwindigkeit gibt wenn sie dann gar nicht verwendet wird. Hätte man zumindest in den Spline Folds richtig machen können. Die kamen ja erst später.

    Eigentlich ein Punkt für die Wunschliste, wenn es nicht schon drin steht.

    Es bleiben IMHO nur die Möglichkeiten:

    - Alles in Expertenbefehlen schreiben, dann benötigt man zum Teachen 'Experttech', oder ein spezielles Teachprogramm mit exakt gleichen Punktnamen wie im Fahrprogramm.

    - Man nimmt 'Usertech' und baut die Bewegungsbefehle selber korrekt nach. Das ist sehr mühsam und kann frustrierend sein, da die Usertech Syntax/Funktion recht eigenwillig ist.

    Aus diesen Gründen wird dann meist am Override rummanipuliert (jetzt gibt es immerhin $OV_APPL, ist aber etwas undurchsichtig), um die Geschwindigkeit zu beeinflussen. Das ist dann immer der bequemste Weg, leider imho auch der schlechtere.

    Die einzige universell funktionierende Lösung dürfte sein:

    Man nimmt zwei Zonen. Die erste äußere sorgt für Reduzierung, die zweite innere überwacht dann auf die reduzierte Geschwindigkeit. Ist ungünstig, da man eben wieder mehr Raum um den Roboter herum benötigt. Aber er benötigt Zeit und den Raum um von der schnellen auf die reduzierte Geschwindigkeit zu kommen.

    Bei dem Ursprungsprogramm gibt es mehrere, nennen wir es mal 'unsaubere Dinge'

    Submit läuft vollkommen asynchron zum Hauptinterpreter, kann also jederzeit zwischen zwei Zeilen unterbrochen werden, das muss also immer bedacht werden.

    - zwischen Ab-/Anwahl/Start eines Programms hat irgendwann mal die Variablen $Base keine Werte (d. h. NICHT dass da Nullen drinstehen, beim Zugriff darauf kommt ein Fehler) in Folge dessen kommt auch ein Fehler beim Zugriff auf $pos_act, da diese sich auf eben $base bezieht.

    - Daher sollte ohne weitere Maßnahmen das Programm aus dem Ausgangspost bei Anwahl eines Programms angehalten werden, kann also gar nicht problemlos funktioniert haben. Daher die Sache mit on_error_proceed.

    -aus dem selben Grund ist ein komponentenweiser Zugriff auf $pos_act (also einzeln auf die Koordinaten x, y, z... wie $pos_act.a usw.) keine gute Idee, zwischen den Zeilen kann immer wieder unterbrochen werden, also kann sich der Roboter da auch weiterbewegt haben, dann sind Koordinaten nicht mehr zum selben Zeitpunkt aufgenommen worden.

    - die Sache mit inGrundstellung im Ausgangspost kann man sich sparen, diese Funktion ist seit der KRC1 (wahrscheinlich schon zu Zeiten der RCM) im Grundsystem vorhanden. Man kann einen Ausgang definieren, der gesetzt wird wenn sich die Roboterachsen im Bereich um xhome (bzw $h_pos, einfach auf der Steuerung mal ein neues Standard Programm aus dem template erstellen und den Fold 'ptp home' aufmachen, da sieht man die Zuweisung zu $h_pos)

    - Genau die selbe Funktion ist für 3 oder 4 (genaue Anzahl müsste ich nachsehen) weitere Positionen integriert. Nachteil ist, dass die Punkte als Achskoordinaten abgelegt werden müssen.

    - Wenn man mehr Positionen überwachen will, kann man die weiteren oben genannten Methoden verwenden: Workspaces, Submit wie bisher, aber mit Korrekturen,

    - Safe Räume verwenden, kann man schon, ist aber, sorry, reichlich daneben. Da man nach Teachen im Programm evtl. die Safekonfig ändern muss, wer sich das antut ist selbst schuld. ;)

    - Auch mit Bases sollte das Programm aus dem Ausgangspost funktionieren, denn die eingelesen Positionen aus $pos_act beziehen sich immer auf das aktuelle $base und aktuelle $tool genau gleich wie die einzelnen Teachpunkte. Da ist was anderes faul. Erkläre doch mal:

    , und nun geht's nicht mehr.

    Könnte sein, dass mehrere Positionen gleichzeitig erkannt werden, da die Teachpunkte in Bezug auf die jeweilige Base ähnliche Koordinaten haben. Da helfen dann wirklich nur noch workspaces, oder die homepositionen, oder man bezieht im submit bei der Berechnung die aktuelle base mit ein. Nichts ist unmöglich.

    Übliche Vorgehensweise ist: SPS-Programmierer multipliziert Achswert mit 100 und rundet. Den Wert sendet er als Ganzzahl (Int oder Word). Der Roboterprogrammierer macht die +-Unterscheidung anhand des höchsten Bits (if > max then minus...) und teilt das Ergebnis wieder durch 100.

    Nicht unbedingt, siehe How to ... ein REAL am Gruppeneingang korrekt in eine REAL-Variable schreiben

    Roboter kann signed Integer lesen, wenn sie 32 Bit breit sind. Da wird das höchstwertige Bit als Vorzeichen benutzt, und zwar unabhängig davon wie das jetzt in WoV deklariert wurde (also INT, DINT, Byte, oder was auch immer es da gibt. Es gilt nur die Deklaration als Signal im .DAT/.SRC

    Stimmt, die Unterscheidung Motorola- / Intelformat habe ich verpennt. Da müssen leider die Bytes geswapped werden. Wir machen das meistens auf der SPS (Siemens), da ist das einfacher und übersichtlicher, als die undurchsichtige Verschaltung im WoV. Keine Ahnung ob es in TwinCat genau so einfach wie auf der Siemens SPS ist.

    Wenn man es in WoV machen will/muss, dann muss man leider die entsprechende Anzahl Bits zusammenfassen und swappen (Punkt 8 im ersten Bild von Fubini), oder in der E/A-Verschaltung byteweise 'falsch herum' zuweisen.

    Viele Wege führen zum Ziel. ;)

    Beim 'debuggen' solcher Fehler generell immer mit einfachen Zahlen ausprobieren, sowas wie '3', da weiss man es sollten genau 2 Bits gesetzt sein. Dann auf der Schnittstelle diese 2 Bits suchen, dann darüber nachdenken was da jetzt wohl falsch gelaufen ist (falls es nicht auf Anhieb funktioniert). Anschliessend mit den komplizierteren Zahlen probieren: 257, -1, -2 usw.

    Das kannst dir auch alles sparen. Kannst einfach nur einzelne Bits verschalten.

    Erst im Programm/Dat-File wird letztlich festgelegt wie viele Bits zusammengefasst werden und welche Werte übertragen werden.

    signal achswert $out[1] to $out[32]

    funktioniert unabhängig davon wie die E/A Verschaltung im WoV aussieht.

    Viel weniger Arbeit und funktioniert problemlos.

    .. Die Byte Reihenfolge habe ich auch getauscht.

    Wo und wie? Da dürfte das Problem liegen.

    Wie kann ich eine Real (Gleitkommazahl) übertragen?

    halbesYoyo
    September 16, 2020 at 3:16 PM

    Wie kann ich den Status der Feldbusvariablen ansehen ? - geht das nur über das Smart Pad, oder kann ich den Status auch im Workvisual online sehen? das wäre wesentlich einfacher

    Sollte in wov gehen, unter den Online Funktionen, aber einfacher als am Smartpad ist das nicht wirklich.

    Es gibt kein SAK in EXT Modus....

    So ist es, allerdings kommt seit KRC1 Zeiten eine Meldung nach Umschalten in EXT, dass die SAK Fahrt notwendig wäre. It's not a bug, it's a feature ;).

    Andererseits kann man in der Sps das Signal $on_path oder $near_posret als Voraussetzung für einen Start verknüpfen, dann braucht's doch wieder die SAK Fahrt. Wird öfter mal gemacht, damit wird die Crashgefahr nach Handverfahten etwas verringert.

    Habe bei Greifervermessen 10mm Fehler gemessen :)

    Da stimmt was nicht. Wenn Du da einfach einen TCP mit der 4-Punktemethode vermessen hast und 10mm Fehler rausbekommst, dann mach das nochmal, und zwar so lange bis ein Fehler unter 1mm rauskommt! Wenn das absolut nicht machbar ist, dann ist der Roboter falsch justiert, oder die Maschinendaten stimmen nicht. Mit sowas kann man keine Vision-Anwendung realisieren.

    Ja, da wird immer der letzte Wert reingeschrieben und bleibt dann erhalten. Das ist quasi der Speicherplatz für die Variable. Das ist etwas anders als bei ABB, mit seinen 3 VAR/PERS/CONST Dingern. Entspricht also einem PERS bei ABB.

    Code
    Decl real x=100.2

    Wenn man hinter die Variable den Wert schreibt, überlebt der letzte Wert einen Neustart. Vorausgesetzt es gab keinen Komplettabsturz.

    Geht auch mit Punkten, einfach in einem beliebigen dat file nachsehen wie das aussieht, wenn im src Punkte geteacht wurden, stehen da auch die Punktedaten drin, die nach einem Neustart auch immer erhalten werden.

    .. Ich arbeite in einer Firma die mit Textilien zu tun hat ..

    Super, biegeschlaffe Teile mit einem Roboter handeln, ist eine spezielle Sache.;)

    .. wie man 3D-Kameras in die Robotersteuerung mit einbaut ..

    Warum denn 3D? Wenn ein Textil auf einem Förderband liegt, dann liegt das doch flach. Sollte es aber auch als 'Haufen', d.h. einfach irgendwie auf das Band 'geworfen' werden, dann mein Rat: vergiss es gleich, das bekommst du mit vernünftigem Aufwand nicht gebacken ( .... aber warte mal, da gibt es ja noch KI, damit geht es auf jeden Fall :biggrins:)

    .. wie bekommt man die Informationen dann in das Roboterprogramm, dass dieser weiß wo er hingreifen muss?

    Über die gängigen Schnittstellen, Profinet, EtherCat, Ethernet/IP oder TCP/IP Sockets. Das ist auch nicht anders als bei einer SPS.

    .. welche in erster Linie für statische Objekterkennung gedacht sind.

    Was meinst Du damit?

    die Kamera muss erkennen, dass auf dem Band ein Wäscheteil liegt und muss dem Roboter dann sagen WO es liegt und WO der Arm hingreifen muss

    Da liegt der Hase im Pfeffer. Du musst erst mal eine Kamera finden, die deine Wäscheteile erkennt. Das hat nix mit Robotik zu tun. Der Rest ist dann mehr oder weniger Standard, und in tausenden Anlagen schon realisiert.

    Dann fehlt noch ein vernünftiges Greifkonzept für die vielen verschiedenen Textilien um sie zuverlässig zu greifen ohne sie zu zerstören, auch das hat erst mal mit einem Roboter selber nicht soo viel zu tun.

    Stichworte zur selbständigen Suche bei Google oder Youtube.

    Roboter Hand Auge Kalibrierung

    Roboter Vision

    Nun meine Frage muss ich am "inb6=6,0,x1" etwas ändern oder eine weitere Zeile für das neue Modul einfügen.

    Ja, du kannst dir aussuchen ob ändern oder einfügen, aber das reicht nicht.

    Du musst auch eine neue ldb Datei erstellen, in der das neue Modul enthalten ist. Und diese Datei in der pfbms.ini eintragen, oder halt den alten Namen beibehalten. Dazu braucht's den NCM Manager, oder Step7 von Siemens.

    Alles vorausgesetzt du hast keine KRC4, wovon ich aber ausgehe, da du von "inb6=6,0,x1" sprichst, das gibt es ab KRC4 nicht mehr, da müsstest mit Workvisual rumhantieren.