Posts by yuminist

    Wieso fällt PoseMult aus?


    Ein Beispiel:


    wenn ich mich nicht irre, sollte damit der oframe (welcher ja schlussendlich angefahren wird) um 10° Z gedreht worden sein.


    das ganze in eine Schleife verbauen und schauen obs klappt.


    oder habe ich da jetzt etwas grundlegend falsch verstanden?

    Hallo Micky,


    rufe ich die Kamera direkt mit dem Namen aus den Systemparametern auf, bekomme ich den selben Fehler. In der Cam_Busy stehen aktuell nur TPWrite aufrufe und keinerlei Funktionen die in irgendeiner Art und weise auf die Kamerazeiger zugreifen wollen.


    Ich habe eine ähnliche Funktion mit AliasIO gebaut, und dort funktioniert es einwandfrei (Ich zeige am Anfang in einem Event einen Ausgang auf einen anderen allgemeingültigen Namen der verwendet und teils auch übergeben wird)


    //EDIT

    Ich habe es gefunden...es funktionierte nicht weil ich ein Trottel bin :D


    beim Aufruf habe ich stets Cam_Busy(Camera); genutzt....


    bei dem AliasIO jedoch ohne Klammern. Nehme ich die Klammern weg, ist alles in Ordnung.

    Oft sieht man den Wald vor lauter Bäumen nicht....


    Vielen Dank für die Mühen und Hilfestellungen

    Hallo Micky,


    zunächst vielen Dank für deine Mühe aber

    ich denke genau das habe ich getan.

    In meinen Datendeklarationen habe ich ein

    Code
    1. VAR cameradev Camera;

    auf das ich ganz zu Anfang mit

    Code
    1. AliasCamera "Kameraname",Camera;

    zeige. Für mein Verständnis suche ich also in der Konfiguration nach "Kameraname" und verweise das gefundene Gerät auf das Cameradev "Camera" sodass ich Camera anderweitig verwenden kann.


    In meinen Routinen benutze ich das dann wie folgt:

    Code
    1. PROC Cam_Busy (VAR cameradev Cameraname)
    2. ...
    3. Waittime 5;
    4. ...
    5. ENDPROC

    Beim Aufruf dann entsprechend

    Code
    1. Cam_Busy(Camera);

    Dort bekomme ich dann den Argument error(124) welcher besagt VAR parameter is not variable reference or is read only.


    Entweder habe ich in dieser Konstruktion etwas grundlegend nicht verstanden, oder es will tatsächlich nicht.

    Hallo Micky,


    danke für den Tipp!

    Allerdings löst das mein Problem nur bedingt.

    Ich möchte vermeiden dass ich für jede Fehlerbehandlungroutine im Fehleraufruf die Kamera von Hand eingeben muss (das wären in Summe einige stellen).


    Vielmehr möchte ich sowas machen wie:

    Code
    1. (PERS VAR oder Ähnliches) cameradev CameraType:=is7801;

    So könnte ich die Fehlerbehandlungen mit dem Namen "CameraType" programmieren. Für den Fall dass die Kamera mal getauscht wird (oder aus irgendwelchen Gründen geändert) brauche ich damit nur an einer stelle eine Änderung vornehmen statt die ganze Fehlerbehandlung (und sicher auch andere Stellen im Code) durchzuackern.


    Das lässt RAPID aber leider nicht zu.


    Sicher ließe sich das mit "Suchen und ersetzen" auch ändern, aber diese Variante würde mir weitaus besser gefallen.


    Ich hoffe ich konnte mich verständlich ausdrücken.


    //EDIT

    Ich hatte es auch schon mit AliasCamera versucht. So kann ich an einer Stelle einen String angeben und meinen eigenen Kameranamen verwenden.

    Allerdings löst es das Problem mit der Übergabe nicht. Zwar habe ich die vorhergehende Meldung durch einfügen des 'VAR' wegbekommen, dafür taucht nun der bei mir so beliebte Argumentenfehler 124 (Argument for 'VAR' parameter <platzhalter> is not variable reference or is read only.) auf.


    Im Grunde also eine Wahl zwischen Regen und Traufe.

    Mahlzeit,


    leider ein Thema über das ich nun schon einmal gestolpert bin. . .


    Folgende Situation:

    Ich möchte mir eine saubere Fehlerbehandlung bauen, welche auch diverse Kameras (Cognex) beinhaltet.

    Soll heißen, ich möchte beispielsweise im Fehlerfall "ERR_CAM_NO_RUNMODE" (Kamera befindet sich nicht im Runmodus) in der Fehlerbehandlung eine Routine aufrufen, welche mir den Runmode setzt und das ganze prüft. Hierzu sollte idealerweise die Kamera mit übergeben werden sodass ich das nicht für jede Kamera tun muss.


    Sähe dann in meiner Vorstellung aus wie

    Code
    1. PERS cameradev Camera:=is7200;
    2. IF ERRNO=ERR_CAM_NO_RUNMODE THEN
    3.     Cam_SetRunmode(Camera)
    4. ENDIF

    Jetzt werden sicher einige bemerkt haben, dass sich der datentyp "cameradev" nicht übergeben oder in eine Variable stecken lässt.

    So kommt bei ValToStr(is7200) zum beispiel die Meldung es handle sich nicht um ein Value.


    Kennt jemand die korrekte Vorgehensweise oder einen Workaround dafür?

    Hallo Jens,


    soweit ich mich erinnere, finden diese Einstellungen in den Sicherheitseinstellungen statt. Dort können Motormomente, Leistungen und andere Einstellungen vorgenommen werden.

    Diese findest du (achtung meins ist englisch) unter Program Robot => Installation => Safety (passwortgeschützt) => General Limits => Advanced Settings


    Anbei ein Screenshot wie das aussehen sollte:


    Dort kannst du jetzt ihm Rahmen der Möglichkeiten deine Einstellungen vornehmen.

    Wofür soll die Weltzone eingesetzt werden?


    Wie ich das sehe ist eine bewegte Zone nicht möglich. Aber wenn du nur abfragen möchtest, ob das Tool in der Zone ist oder nicht, was spräche dagegen das Werkobjekt welches sich zum Toolbewegt abzufragen?


    Oder habe ich da etwas gänzlich missverstanden?

    meines wissens nach brauchst du ein signal welches dem roboter die aktuelle stellung mitteilen kann (beispielsweise ein inkrementalgeber)


    ich wüsste nicht ob und wie es ohne gehen könnte.


    wenn es eine konventionelle drehbank ist, stehen die chancen denke ich schlecht - mit cnc maschinen kenne ich mich leider nicht genug aus um eine aussage treffen zu können

    was bekommst du denn an werten von deiner externen achse?


    beispiel: werte kommen von -180 bis 180
    dann könntest du bei jedem sprung von 180 auf -180 einen zähler inkrementieren und hättest somit deine umdrehungen die du nach lust und laune weiterverwenden kannst

    Wenn ich das richtig verstanden habe...


    nimmst du mit CrobT die aktuelle Position auf (beispielsweise in eine PERS pTemp)....dann kannst du vergleichen ob es dieses target schon gibt (hierzu würden ja die trans und rot werde ggfs. reichen) ... falls diese prüfung negativ ausfällt kannst du es ggfs. als neues RobTarget erstellen.... da bin ich allerdings überfragt - allerdings könnte dir eventuell dieser thread hier weiterhelfen
    https://www.roboterforum.de/ro…laufzeit-erstellen/13705/

    Hängt vom Netzwerk ab in dem die Steuerung läuft - der Serviceport schreit recht laut und vor allem schnell als DHCP ins Netzwerk.


    Ich hatte das Problem hier mal versehentlich verursacht und die ganzen Rechner im Netzwerk bekamten die IP dann vom Serviceport weil dieser wesentlich schneller war als der eigentliche Router

    Moin,


    folgende Situation:


    auf einem Förderband werden Produkte klassifiziert - iO nIO halb iO oder was es da noch so geben soll. Das ganze wird über DI übergeben (beispiel alle aus heisst nio - di1 an ist dann io usw...)
    soweit ist das auch klar...aber


    für die Klassifizierung wird das Förderband nicht angehalten. Erst am Roboter selbst werden die Produkte zur Entnahme gestoppt (denn soweit ich das sehe kann UR noch kein ConveyorTracking)


    demzufolge entstand die Idee, dass eine FiFo Liste angelegt wird, anhand derer der UR dann erkennen kann, welche Klassifizierung das aktuell ankommende Produkt nun hat. Das Ganze hat nun zwei Haken:
    1. Ich bin mir noch unschlüssig wie ich sicherstelle, dass ich merke sobald die Liste durcheinander kommt (beispielsweise bleibt ein Produkt aus irgendeinem Grund hängen und wird zwei mal klassifiziert)


    2. muss auf die FiFo Liste parallel zugegriffen werden. Und zwar einmal schreibend am Ende sodass für die fortlaufende Produktnummer eine Klassifizierung hinterlegt wird, und einmal Lesend vom UR (ja und später auch schreibend um den Eintrag zu entfernen) um dem aktuellen Bauteil die Klassifizierung entnehmen zu können.


    bei den großen (teuren) stellt das kein Problem dar. Parallele Prozesse beim UR ist allerdings meine persönliche Premiere und ich frage mich, wie das dort ablaufen könnte. Geht das direkt über das Linux-System in einem Hintergrund-Task oder läuft das über die Python-Scripte in der UR Oberfläche? Diese werden meines Wissens nach ja auch seriell und nicht parallel abgearbeitet?


    //EDIT
    okay wer das Handbuch richtig liest, entdeckt auch den 'Thread'-Befehl :pfeif:

    muss zwingend das gesamte koordinatensystem gedreht werden?


    so wie ich das sehe, reicht es den oframe zu drehen/schieben denn dieser ist der der angefahren wird.


    Code
    1. ptemp:=pdeinreferenzpunkt
    2. wtemp:=wdeinwerkobjekt
    3. wtemp.oframe.rot:=OrientZYX(90,0,0);
    4. MoveL ptemp, v1000, z30, tool1\wobj:=wtemp;
    5. wtemp.oframe.trans.x:=30; !hier deine inkremente die du abtasten willst in einer achse


    das ganze kannst du dir in eine kleine routine packen und den referenzpunkt übergeben sowie ggfs die dreheung
    hier fehlt natürlich noch die palettierungsfunktion die entscheidet, nach wievielen punkten oder welchem maß das raster eine zeile weiter springen soll.


    habe ich das so korrekt aufgefasst?


    alternativ:
    du sagtest du da hast einen geteachten (referenz-) punkt.
    wieso drehst du diesen nicht und schiebst ihn mittels offsets? das ginge sicher auch

    Micky


    vielen Dank für diese Aufschlussreichen Infos


    Dass robtargets nicht pers sein müssen war mir neu -.-


    Quote

    Da deine Zone kein optionaler Parameter ist, macht die Abfrage "IF Present(Zone)" keinen Sinn, da dieser Parameter immer vorhanden ist.


    das hätte ich fast übersehen - war ein überbleibsel und natürlich völlig korrekt dass das so keinen sinn macht :)



    @was
    auch das funktioniert :)


    ich danke euch

    Moin,


    auch wenn so kurz vor dem Wochenende:


    Ich habe mir folgendes geschrieben: (über Sinn und Unsinn kann man sicher streiten)

    Code
    1. PROC Test_Move2Pos(PERS robtarget pTarget,PERS tooldata tTool,PERS wobjdata wWobj,num Offset{*},speeddata TravelSpeed,zonedata Zone\switch Finepoint)
    2. IF NOT Present(Zone) THEN
    3. MoveJ Offs(pTarget,offset{1},offset{2},offset{3}),TravelSpeed,z5,tTool,\WObj:=wWobj;
    4. ELSE
    5. MoveJ Offs(pTarget,offset{1},offset{2},offset{3}),TravelSpeed,Zone,tTool,\WObj:=wWobj;
    6. ENDIF
    7. IF Present(Finepoint) MoveL pTarget,TravelSpeed,fine,tLocal\WObj:=wWobj;
    8. ENDPROC


    jetzt habe ich folgendes im weiteren Verlauf versucht:

    Code
    1. Test_Move2Pos RelTool(pReorient,0,0,-20),tGripper,wReorient,[0,0,0],vPlace,z0\Finepoint;


    und bekomme dann

    Quote

    [...](38,22): Argument error(123): Argument for 'PERS' parameter pTarget is not a persistent reference or is read only. 17.05.2019 14:08:24 General


    mein Problem liegt nun darin, dass ich mir zwar denken kann worüber er sich beschwert (vermutlich werden die Daten nicht als robtarget wie gewünscht übergeben), aber leider keinen Ansatz habe wie ich das beheben kann ohne 400 weitere Funktionen oder Routinen zu schreiben.


    Ist das so überhaupt machbar oder sehen die Praxiserfahreren Damen und Herren da einen besseren Weg?


    Grund ist im Übrigen dass ich das Programm schlank und lesbar halten möchte.


    Ein schönes Wochenende wer hat

    so - sorry für die verzögerung


    Sebastian78
    du hast mich da etwas falsch verstanden - ich bekomme von zwei kameras je einmal translations- und rotationsdaten
    diese werden dann getrennt voneinander verarbeitet.
    pro kamera bekomme ich also x und y sowie ein rotationsoffset


    im grunde also genau das, was posemult braucht (eine pose)


    mittlerweile habe ich das problem des versatzes gefunden und behoben


    es lag wie programmiersklave schon richtig anmerkte, an kleinigkeiten. das koordinatensystem von kamera und roboter war nicht exakt synchron (da muss ich mal schauen wie man das besser einrichten kann) und der TCP war nicht zu 100% rotationssicher (wird dann wohl in naher zukunft elektronisch vermessen)


    alles in allem also die summe kleinerer abweichungen

    Sebastian78


    Die Stoßrichtung des Werkzeugs ist korrekt (ich weiß gar nicht wie oft ich das mittlerweile geprüft habe XD) und ich habe es sogar soweit dass es "rotationstreu" ist. Sprich drehe ich das Tool um Z um eine Spitze, bleibt diese wo sie ist (ist bei händischer Kalibrierung nicht selbstverständlich)


    Warum ich die Translation im oFrame und die Rotation im uFrame machen sollte, erschließt sich mir noch nicht.
    Im Grunde gibt es doch genau für solche Zwecke "PoseMult", oder nicht?


    Mit der Rotation an sich habe ich weniger Probleme (die Rotatorische Ausrichtung passt ja) - nur der Versatz in XY irritiert mich.


    Ich denke das Hauptproblem ist - wie Programmiersklave schon anmerkte - dass dies ein Grenzbereich ist. Ich versuche mich hier so weit es geht unter einem Zehntel genauigkeit zu bewegen.


    Nachdem ich mich die letzten Tage wesentlich mit den Tools, dem Referenzobjekt und den Objektträgern beschäftigt habe, komme ich langsam zum Schluss, dass man über eine rein elektronische Kalibrierung nicht drum herum zu kommen scheint wenn man sich in diesem Bereich zuverlässig bewegen will.