Beiträge von yuminist

    Digitale Eingänge bei Robotern direkt zu verdrahten stellt meist ein Problem dar.


    Um ein Koppelrelais oder Ähnliches kommt man im Regelfall nicht drum herum wenn man derartige Probleme/Phänomene vermeiden will. Es kann bei derartigen Konstruktionen immer wieder zu Effekten kommen die man nicht will - kurzum: das ganze ist dann alles andere als stabil.

    Hallo micha,


    ob die achse die daten liefert, könntest du zunächst überprüfen indem du den motortorque oder ähnliches versuchst auszulesen.

    was die motion supervision angeht - afaik sollten die geometrien soweit hinterlegt sein, dass diese korret funktioniert. einen fehlerhandler dazu gibt es meines erachtens nach auch (einfach kurz in die doku schauen - das habe ich erzeit nicht im kopf)

    Ja stumpf die Positionen zu vergleichen ist nicht wirklich sicher da gebe ich dir recht - in Hinblick auf den Kontext war das auch als Ansatz gedacht.


    Die Vorgehensweise die du beschreibst war mir neu, ist aber wie ich finde auch sehr ausgeklügelt und macht absolut Sinn.

    Zitat

    2.26. CRobT - Reads the current position (robtarget) data

    bitte einmal im entsprechenden Kapitel nachsehen


    Leider hast du die Frage nach der Generation deiner Steuerung offen gelassen. Ob dieser Befehl auch schon in der 4 vorhanden war, kann ich leider nicht sagen.

    du könntest auch die aktuelle position mit CRobT vergleichen


    Code
    p_temp:=CrobT();
    
    IF p_temp=p_fass THEN ... 
    
    ELSEIF p_temp=p_reiniger THEN ...
    
    ENDIF

    Die Frage hierbei ist natürlich, ob die Angaben aus CRobT genau genug für einen Vergleich sind. Das könnte man aber Lockern indem man nicht alle Parameter vergleicht, sondern lediglich die xyz Koordinaten.

    Weiter musst du darauf achten, dass der Roboter auch wirklich an der Position steht (WaitRob\Inpos zum Beispiel nutzen) da der PZ ja voraus eilt und du damit ggfs die falsche Position ermittelst.

    Hallo LB,


    hilfreich wäre ein Ausschnitt des Codes den du benutzt um die datei vom FTP zu holen, und/oder zu verbinden.

    Ebenso vielleicht die Maßnahmen die du bereits ergriffen hast. "Alles mögliche" ist da leider nur wenig aussagekräftig :)


    Die Fehlermeldung an sich reicht da leider nur bedingt um eine Aussage treffen zu können.

    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
    VAR cameradev Camera;

    auf das ich ganz zu Anfang mit

    Code
    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
    PROC Cam_Busy (VAR cameradev Cameraname)
    ...
    Waittime 5;
    ...
    ENDPROC

    Beim Aufruf dann entsprechend

    Code
    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
    (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
    PERS cameradev Camera:=is7200;
    
    IF ERRNO=ERR_CAM_NO_RUNMODE THEN
        Cam_SetRunmode(Camera)
    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/