Beiträge von JaNiKu

Hallo zusammen,
vielen Dank für die Tipps und sorry für die späte Reaktion.
Ich war, bzw. bin seit Eröffnung des Themas krankgeschrieben und habe das so gesehen auch mal ernst genommen die letzten Tage.

Sehr gute Anregungen/ Tipps.
Ich werde das dann mal mit meinem Chef und auch dem Kunden klären.
Eventuell ist die Geschichte mit dem Stop elegant, da es sich um eine Bestandsanlage von einem anderen Hersteller handelt, bei der das nachgerüstet werden soll. Da wühle ich immer gerne so wenig wie möglich in der Safety rum, um mir diesen Schuh nicht anziehen zu müssen.
Ansonsten würde ich am ehesten dann auch über den General Stop gehen, das finde ich persönlich gut.

Viele Grüße und nochmals Danke

Hallo zusammen,

falls ich es nicht gefunden habe, entschuldige ich mich schonmal, aber ich kann zu dem Thema nichts 100%ig passendes finden:

Es besteht die Anforderung über das Stecken eines EKS (PFID) mit entsprechender Freigabe an der SPS das Fahren des Roboters in Handbetrieb zu koppeln.
Soll bedeuten: Ohne entsprechendes EKS soll ein Fahren in Hand-Betrieb nicht möglich sein.

Zudem soll das Ganze an die Schutztüren so gekoppelt sein, dass nur eine Schutztüre offen ist (aber das sind ja dann alles SPS-interne geschichten).
Es geht also um die Freigabe der Funktion durch die SPS.

Bzw. ist eine Kopplung der Benutzerverwaltung an die SPS möglich?
Es handelt sich um einen SafeMove Roboter.
Mir selbst fällt da nur ein, den sdi_SafetyEnable in der SPS an den sdo_ManualMode zu koppeln und dann eben ohne EKS zu entziehen.
Das erscheint mir aber nicht so ganz sauber.
Gibt es da vielleicht eine bessere Lösung? Ich bin mir sicher, dass das hier schon 100mal umgesetzt wurde, oder?

Danke vorab.
Grüße
Jannis

Nochmal Hallo,

ich konnte da doch noch etwas erreichen und würde das gerne auch teilen entsprechend.
Es gibt ein KAREL-Programm "MATRIX", das die Matritzenmultiplikation ausführen kann.
Ich habe es implementiert und getestet.
Erste Testergebnisse zeigen, dass der Frame schön verschoben wird.
Da ich nur eine einfache Rechteckerkennung gemacht habe, die natürlich wegen der Symmetrie den Frame ab und zu um 180° dreht ist alles unter Vorbehalt
Es sei beachet, dass beim Fanuc-Service mir jemand sagte: Finger weg.
Also auf eigene Gefahr...:

19: !frame shift ;

20: !transfer master frame to PR ;

21: PR[9:MasterMatrix]=UFRAME[2:MasterFrame] ;

22: !store xyzwpr to PR to check if valid ;

23: CALL INVERSE(9,10) ;

24: CALL INVERSE(10,10) ;

25: !get vision offset ;

26: CALL IRVSTRUNFIND("Vision Process"='FRAME_SHIFT') ;

27: VISION GET_OFFSET 'FRAME_SHIFT' VR[1] JMP LBL[99] ;

28: !store offset in PR (matrix form) ;

29: PR[8]=VR[1].OFFSET ;

30: !matrix multiplication of offset and master frame;

31: CALL MATRIX(8,9,11) ;

32: !store matrix of result ;

33: CALL INVERSE(11,12) ;

34: !result of multiplication is the new frame ;

35: UFRAME[3:ShiftFrame]=PR[11:ShiftFrame] ;

Ein schönes Wochenende!

RoboGuide ist als Testversion vorhanden.
ASCII-Uploader nicht.
Aber Ich werde so vorgehen.
Vielen Dank

Hallo,
danke für die schnelle Hilfe.
So in etwa habe ich es vermutet. Konnte es aber nicht so ganz greifen.
Dass eine einfache Addition so nicht funktioniert ist dann auch klar.
Wie man aus dem ganzen eine vollständige Transformation in einer Fanuc-Steuerung bastelt ist mir aber leider auch nicht geläufig.

Die Winkel sind hier tatsächlich das verfluchte.
Es wird tatsächlich darauf hinauslaufen, dass man auf die Zielpunkte den Vision-Offset mit draufrechnen muss.
Da es sich um viele Punkte handeln würde wäre eine Frame-Verschiebung "sauberer" gewesen.
Das war meine Hoffnung.

Zitat von Gerhard Reinig

Master-Userframe einmessen.
Daten in ein Positionsregister (1) schreiben.
Bezogen auf dieses Positionsregister (1) mit den Offsets ein Offest-Positionsregister (2) schreiben.

Userframe=Positionsregister (2).
Funktioniert auch mit Tool-Frames.

Hallo,

ich würde die Thematik gerne nochmal aufgreifen.
Derzeit bin ich an demselben Thema dran.
Ich habe das Verfahren ausprobiert:

19: !frame shift ;

20: //PR[10:OLT-MasterFrame]=UFRAME[2:OLT-MasterFrame] ;

21: CALL IRVSTRUNFIND("Vision Process"='FRAME_SHIFT') ;

22: VISION GET_OFFSET 'FRAME_SHIFT' VR[1] JMP LBL[99] ;

23: PR[8]=VR[1].OFFSET ;

24: CALL INVERSE(8,9,10) ;

25: PR[11,1:shift frame]=PR[10,1:MasterFrame]+PR[9,1:offset] ;

26: PR[11,2:shift frame]=PR[10,2:MasterFrame]+PR[9,2:offset] ;

27: PR[11,3:shift frame]=PR[10,3:MasterFrame]+PR[9,3:offset] ;

28: PR[11,4:shift frame]=PR[10,4:MasterFrame]+PR[9,4:offset] ;

29: PR[11,5:shift frame]=PR[10,5:MasterFrame]+PR[9,5:offset] ;

30: PR[11,6:shift frame]=PR[10,6:MasterFrame]+PR[9,6:offset] ;

31: UFRAME[3:OLT-ShiftFrame]=PR[11:shift frame] ;

In PR[10] habe ich händisch mein Master-Frame eingetragen.
Die Berechnung der Inversen mache ich, da die Offsetdaten des Vision-Process in Matrixform ausgespuckt werden.
Nach Kontakt mit Fanuc hat man mir von dem ganzen VErfahren eher abgeraten, da die BErechnung der Inversen wohl oft fehlerhaft ist.
Diese Erfahrung habe ich jetzt auch gemacht. Der Offset haut mir bei der VErschiebung komplett ab.

Könnten Sie das Ganze für mich vielleicht etwas genauer erklären oder bestätigen, dass es oft schief geht?

Vielen Dank vorab!
Grüße