Robtarget verriegeln

  • Hallo Kollegen,


    fällt jemandem eine Lösung ein, wie ich ein Robtarget "unteachbar" mache?

    Hintergrund ist, dass irgendein schlauer Linienführer bei uns die Prüfpositionen für MIG und Bolzenköpfe teacht, wenn diese nicht passen und der Schuldige weder auffindbar noch belehrbar ist.


    Schönen GRuß,

    ABB-Nutzer

  • Wie wäre es die Robtargets aus dem Modul rauszuholen und in ein READONLY oder VIEWONLY Sysmodul zu packen?


    Das wäre jetzt so meine erste Idee

  • Wir hinterlegen sämtliche relevante Daten in ein separates MODUL und dies wird dann als VIEWONLY deklariert.

    bzw. kann man sich ja auch eine andere Variable erstellen und diese dann immer übertragen vor der Verwendung.


    Gruß

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

  • Schon einmal darüber nachgedacht die UAS anzupassen und dem DEFAULT Nutzer das Ändern von Position nicht mehr zu erlauben?

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

  • Das Problem ist, dass man in der UAS nur alle oder gar kein ändern erlauben kann. Da der Linienführer aber hier und da mal was teachen muss, würde ich das nur ungern machen. Vermutlich hilft hier nur weiter unterweisen.

  • Ja oder in deinem Fall eine andere Positionsvariable anlegen und die eigentliche Position damit immer überschreiben vor der Verwendung. ;-)

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

  • Mir sagt jetzt die KorPos Funktion nichts, aber die kann ein als CONST definiertes Robtarget in einem Schreibgeschützten Modul anpassen? o.0

  • Jupp das kann die, sowie auch eine Zuweisung von Daten innerhalb des Programms.

    Das Programm hat sämtlichen Zugriff, wie auch die KorPos-Funktion.


    Gruß

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

  • wieder was gelernt

    ich hatte von meinen letzten Spielerein das anders im Hinterkopf, aber wie das so mitm Hinterkopf ist und dem was der sich zusammenspinnt :whistling:

  • So hab da jetzt mal im RobStudio probiert.

    Wenn du deine Routine in ein Modul mit VIEWONLY packst kannst du dort nichts teachen.


    Wie hast du das bei dir probiert ABB-Nutzer ?


    Okay erstellt jemand eine Bewegungsinstruktion in einem anderen Modul und verwendet deine Variable bist du hin, außer du kannst es von deinem Programm her als LOCAL deklarieren?


    Gruß

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

  • Ich habe die entsprechende Robtarget-Deklaration in ein eigenes Modul geschoben und dieses als ViewOnly bzw. READONLY deklariert. Das funktioniert aber wohl nur, wenn der Programmzeiger in dem entsprechenden Modul steht - von außen ändern geht definitiv. Wir verwenden den Konzernstandard, daher sind alle Serviceroutinen (Alles mit Docking, TCP-Kontrolle etc.) in einem Modul. Das gesamte Modul entsprechend zu deklarieren geht leider nicht, da hier eben ab und an Teacharbeiten vorgenommen werden müssen. Somit gibt es eigentlich nur die Lösung, die Kontrollroutine in ein eigenes Modul zu schieben und das Modul via ViewOnly zu schützen. Unschön.

  • "Verstecke" doch die robtargets in einem Offs(robtarget,0,0,0) oder RelTool(...). Damit sind die Positionen zumindest nicht direkt nachteachbar.

    Ausserdem hat der Linienführer auch einen optischen Hinweis das diese Position eigentlich nicht nachgeteacht werden soll.

    Evtl. kann man zusätzlich das programmieren weiterer Bewegungsbefehle im UAS verhindern (weiss ich jetzt auswendig nicht).

  • Guten Morgen
    Ich kann nur Empfehlen, die UAS ausgiebig zu konfigurieren. Hier kann jeder Mitarbeiter seine eigenen Rechte per Benutzergruppe erhalten, die man alle vollkommen unabhängig konfigurieren kann. Damit ist zwar nicht ausgeschlossen, das geteacht wird aber viel wichtiger ist die Tatsache, dass ihr sofort Personenbezogen wisst, welche Änderung von welcher Person durchgeführt wurde und könnt diese dann entsprechend "Unterweisen".


    Welche Funktion im UAS auch sehr wichtig ist, ist der Schlüsselschalter.

    Wenn dieser nach einem Techvorgang wieder auf Automitik gestellt wird, dass sich das System sofort wieder in den Default User schaltet / abmeldet und wenn ihr diesen Default User dann bis auf fasst alles "beschränkt" habt, kann auch keine andere Person etwas verändern.

    Wir hatten bei uns im Unternehmen genau die selben Probleme und seit dem die Mitarbeiter wissen, dass ihre "Taten" Personenbezogen protokoliert werden, war ganz schnell Ruhe im Karton.

    Das schöne ist auch, dass ihr euch nur einmal die Arbeit machen müsst um das UAS zu konfiguriren. Danach kann dieses Profil einfach auf die anderen Roboter exportiert werden.