Beiträge von halbesYoyo

Moin,

das hängt vom Modell, der genauen Stellung der Achsen und den Achskonfigurationen ab.

Wenn der FANUC ziemlich gestreckt steht, könntest Du probieren eine zweite Vorpos über dem Bauteil mit L ... MROT anzufahren.

(In dem Beispiel wird vorausgesetzt, daß +Z Stoßrichtung ist und das Bauteil genau in Stoßrichtung liegt)

J PR[1:Vorpos] 100% FINE

  ! 10mm von Vorpos Richtung Bauteil in +Z
  PR[3:Offset]=PR[3:Offset]-PR[3:Offset]
  PR[3,3:Offset]=...
L PR[2:Bauteil] 50mm/sec FINE Tool_Offset,PR[3:Offset] MROT

L PR[2:Bauteil] 50mm/sec FINE

Das Offset (Zeile 5) musst Du dabei so wählen, dass Achse 4 da bereits das Achslimit überschritten haben würde. Dann sollte der FANUC wegen des MROT Achse 4 passend umorientieren. Je weniger gestreckt der FANUC steht, desto wilder könnte auf dem Weg zu dieser Position der Tanz ausfallen, den Achse 5 und/oder 6 aufführen, weil die u.U. sehr viel umorientieren müssen.

Bei mir ging das so leider nicht. Ich bekomme auch Zielpositionen von der SPS. Ich habe testweise in 100mm Raster alle Positionen angefahren, um zu schauen, mit welcher Achskonfiguration sie erreichbar sind. Im Programm lade ich nun vorab anhand der Zielposition ein PR mit einer passenden Achskonfiguration aus und schreibe die Zielkoordinaten (XYZWPR) noch dazu. Es bläht den Code auf und sieht nicht schön aus, aber es funktioniert immerhin.

!CONF anhand Zielquadrant laden
IF (PR[78,2:MP pos next part]>(-501)) THEN ;
  IF (PR[78,1:MP pos next part]<101) THEN ;
    PR[70:MP pre pos]=PR[91:FUB]    ;
    PR[71:MP over MP]=PR[91:FUB]    ;
    ...
  ELSE ;
    PR[70:MP pre pos]=PR[89:FDT]    ;
    PR[71:MP over MP]=PR[89:FDT]    ;
    ...
  ENDIF ;
ELSE ;
  PR[70:MP pre pos]=PR[90:FUT]    ;
  PR[71:MP over MP]=PR[90:FUT]    ;
  ...
ENDIF ;

!Positionsdaten schreiben
PR[70,1:MP pre pos]=...;
PR[70,2:MP pre pos]=...;
PR[70,3:MP pre pos]=...;
PR[70,4:MP pre pos]=...;
PR[70,5:MP pre pos]=...;
PR[70,6:MP pre pos]=...;

PR[71,1:MP over MP]=...;
PR[71,2:MP over MP]=...;
...

Gruß

Jörn

Moin Christian,

Du hast bereits Erfahrung mit dem Programmieren, d.h. mit logischen Abläufen. Und als Konstrukteur, davon gehe ich jetzt mal aus, ein gutes räumliches Vorstellungsvermögen. Perfekt!

Wie Hermann schon sagt wären Kenntnisse in der Elektrik sehr von Vorteil. Am Ende des Tages ist es "nur" Spannung liegt an / Strom fließt - oder eben nicht. Ok, ein bissl mehr ist es schon, aber Hexenwerk ist das jetzt auch nicht.

Ähnliches gilt für die Mathematik. Unter der Haube des Roboters, speziell was die Bewegungen betrifft, führt die Mathematik, genauer gesagt die Matrizen, das Zepter. Wirklich in Berührung wirst Du damit eher selten kommen. Es erleichtert einem aber einiges, wenn man die Hintergründe (zumindest) versteht.

Und falls alle Stricke reißen und Du mal doch irgendwo irgendwelche Probleme oder Fragen hast, kannst Du Dich hier im Forum mit sehr umgänglichen, fachkundigen und hilfreichen Mitmenschen austauschen.

Ich würde sagen: Schnapp sie Dir, Tiger!

Gruß

Jörn

Ich hätte jetzt auch das I/O Panel Utility vorgeschlagen:

Moin,

vielen Dank für den Tip. Das läuft so ganz gut, deshalb lass ich es erstmal so. Ich behalte Deinen Tip aber im Hinterkopf.

Perfektes Beispiel!

So sieht das dann jetzt bei mir aus. R[27] bis R[30] werden vorbelegt und direkt vor dem Fahrbefehl wird DO[268] auf ON gesetzt. Der Rest geht dann von alleine.

!DO[268] start = ON, autostop
!  after R[29] values
!R[26] tick (8ms)
!R[27] interval to store [ms]
!R[28] start register
!R[29] no of vales to store
!R[30] pointer to the register
!  to store the next value to
!-------------------------------
IF (DO[268]=ON) THEN
  IF (R[30]>(R[28]+R[29])) THEN
    DO[268]=OFF
  ELSE
    IF (R[26]<R[27]) THEN
      R[26]=R[26]+8
    ELSE
      R[R[30]]=$cr_var[1].$fs_mon[5]
      R[26]=0
      R[30]=R[30]+1
    ENDIF
  ENDIF
ELSE
  R[26]=0
  R[30]=R[28]
ENDIF

Nachtrag:

Mein zweiter Versuch hat übrigens nicht funktioniert, weil man in der BG-Logic mit einem JMP ausschließlich vorwärts (Richtung Programmende / nach "unten" ) springen darf.

Moin,

ich würde an "meinem" CRX gerne in regelmäßigen Intervallen den Wert des Kraftsensors abfragen, um den Kraftverlauf beim Montieren von Bauteilen aufzunehmen. Dazu hab ich mir ein Programm für die Background logic geschrieben. Aber wie auch immer ich es anstelle, ich krieg den Roboter nicht dazu in der BG-logic eine gewisse Zeit zwischen dem Aufnehmen der Werte zu warten. Die erste Idee war diese:

1: R[31]=($cr_var[1].$fs_mon[5])
2: WAIT 0.01(sec)
3: R[32]=($cr_var[1].$fs_mon[5])
4: WAIT 0.01(sec)
5: R[33]=($cr_var[1].$fs_mon[5])
...

Dabei kommt ein INTP-443 Invalid item for Mixed Logic für Zeile 2 bei raus. Ok, seh ich ein. WAIT ist in der Liste der Availiable instructions für die BG-Logic nicht aufgeführt. Dann also so:

1: R[31]=($cr_var[1].$fs_mon[5])
2: R[199:i]=0
3: LBL[31]
4: R[199:i]=(R[199:i]+1)
5: IF (R[199:i]<1000),JMP LBL[31]
6: !
7: R[32]=($cr_var[1].$fs_mon[5])
...

Da gibt es ein INTP-443 Invalid item for Mixed Logic für Zeile 5?! Eigentlich sollte das aber gehen:

Es gibt sogar ein ähnliches Beispiel in der Anleitung:

pasted-from-clipboard.png

Hat jemand eine Idee? Mir gehen sie langsam aus.

Gruß

Jörn

Ja, so kann man es programmieren.

Vergiss beim nächsten Mal bitte die Satzzeichen nicht! Ganz besonders, wenn Du, wie hier, so verschachtelte Sätze schreibst. Ich musste den Text mehrmals lesen.

Nachtrag:

Sliwka

Das war nicht die Frage!

Der Startpunkt ist die aktuelle Position - er soll sich ja von dort mit dem Fahrbefehl zur Zielposition bewegen.

Bei J-Bewegungen wird ja im Voraus berechnet, wie sich alle Achsen bewegen müssen, damit sie gleichzeitig dort ankommen. Deshalb ergibt sich bei diesen Berechnungen auch die Erreichbarkeit und es gibt ggf. ein Not reachable.

Bei L-Bewegungen kommt es drauf an, wie es programmiert ist. Wenn einfach nur die min. Differenz zwischen Start- und Zielposition ermittelt und dann - ohne weitere Prüfung - die Bewegung gestartet wird, dann endet es halt u.U. mit einem Limit error.

Ich hab zwischenzeitlich Hinweise auf die Option MROT gefunden und diese getestet. Wenn man die mit einer L-Bewegungen nutzt, nimmt der Roboter ebenfalls den kürzesten Weg von Start- zu Zielposition, achtet dabei aber auf die Achsgrenzen. Wenn der Zielpunkt "hinter" einer Achsgrenze liegt, wenn er den (real) kürzeren Weg nähme, bewegt sich der Roboter stattdessen anders herum.

In den Systemvariablen finden sich unter $SHELL_CFG diverse Variablen dazu. Welche davon man setzen muss kann ich aber auch nicht sagen. Wenn ich raten müsste, würde ich auf $RSR_ENABLE und $PNS_ENABLE tippen.

Schau auch mal im B-83284-10 Basic Operation Manual im Kapitel 3.8. Da ist ein Beispiel mit JOB als Name für Prog Select mit Style aufgeführt.

Nachtrag:

Wenn die Variable $SHELL_CFG.$SHELL_EXT auf FALSE steht, sieht man in dem Menu nur RSR/PNS als Eintrag. Wenn man sie auf TRUE setzt, wird stattdessen Prog Select angezeigt.

Moin,

bei PNS oder RSR?

Unter [MENU] > [SETUP] > [Prog Select] > [Program select mode] > [CHOICE] steht der aktuelle Modus drin.

Unter [DETAIL] > [Job prefix] kannst Du den Prefix ändern.

Gruß

Jörn

Moin,

sooo, das KAREL-Programm ist fertig.

Der erste anzufahrende Zielpunkt ist per JOINT anfahrbar. Bei LINEAR gibt es eine Meldung MOTN-023 In Singularity (sogar bevor der Roboter sich bewegt). CHECK_EPOS gibt 0 (also erreichbar) zurück.

Beim zweiten anzufahrenden Zielpunkt hab ich genau unsere Situation nachgebildet. Achse 6 steht bei rund 170°, der Zielpunkt ist etwa -300° entfernt, Beim Anfahren mit JOINT dreht er fast komplett rum. Mit LINEAR nimmt er den kürzeren Weg, fährt dabei in die Achsgrenze und gibt den bekannten Fehler SRVO-115 Limit error aus. Auch hier gibt CHECK_EPOS eine 0 (erreichbar) zurück.

Ich hab auch einen mit X=3471.0 ganz bestimmt nicht erreichbaren Punkt getestet. Da gibt CHECK_EPOS korrekt keine 0, sondern den Wert 15018 zurück, was der Fehlermeldung MOTN-018 Position not reachable entspricht.

Es sieht danach aus, als funktioniere CHECK_EPOS nur mit JOINT-, aber nicht mit LINEAR-Bewegungen!? Falls das in den Handbüchern steht, hat FANUC das (mal wieder) gut versteckt.

Gruß

Jörn

Moin PnsStarter,

vielen Dank für die unzähligen Stunden Sucherei, die Du mir erspart hast.

Über das MROT bin ich im englischen Forum schon gestolpert. Das wäre, so wie ich es verstanden habe, eigentlich ziemlich genau das, was ich suche. Blöderweise ist das eine "Optional Function".

KAREL ist kein Problem. Ich hab bereits ein paar Programme geschrieben, u.a. einen tauglichen Zufallszahlengenerator. Von den Beschreibungen her würde IN_RANGE reichen, es wird aber eher CHECK_EPOS, weil ich da nicht erst auf den passenden UFrame und das TOOL wechseln muss. Ich teste das mal.

Gruß

Jörn

Moin,

über einen kleinen Umweg kann man bei ABB vorab die Erreichbarkeit eines (Ziel)punktes ermitteln. Falls er nicht erreichbar ist, wird ein abfangbarer Fehler ausgegeben:

FUNC bool IsRobtargetReachable(robtarget pReach, PERS tooldata tReach \PERS wobjdata wReach)
  VAR bool        bReachable := TRUE;
  VAR jointtarget jReach;
  jReach := CalcJointT(pReach, tReach \Wobj?wReach);
  RETURN bReachable;
ERROR
  IF (ERRNO = ERR_ROBLIMIT) OR (ERRNO = ERR_OUTSIDE_REACH) THEN
    SkipWarn;
    bReachable := FALSE;
    TRYNEXT;
  ENDIF
ENDFUNC

Gibt es sowas in der Art auch bei fanuc? Von mir aus auch irgendwie als workaround.

Ich frage deshalb, weil mein Programm ab und an mit der Meldung SRVO-115 Limit error stehenbleibt: von einer Startposition soll der Roboter linear eine (von einer Kamera ermittelte) Zielposition anfahren. Wenn aber z.B. Achse 6 an der Startposition bei 182° steht und an der Zielposition einen Winkel von 253° hätte kann das nicht gehen, weil der Achsbereich der Achse von -220° bis 220° geht.

Blöderweise kann diese spezielle Bewegung nicht in joint erfolgen, weil es die Bewegung auf das Bauteil ist. Meine Idee wäre deshalb vorher zu prüfen, ob die Position erreichbar ist, und, falls nicht, eine Zwischenposition über dem Bauteil per joint anzufahren. Immer eine entsprechende Zwischenposition anzufahren soll möglichst vermieden werden, weil es unnötig die Taktzeit verlängern würde.

Gruß

Jörn

Es geht darum eine Rüttelbahn in einer background logic anzusteuern. Wenn der Sensor am Ende der Rüttelbahn / vor dem Topf, in den die Bauteilen sollen, nicht belegt ist, soll sie rütteln / nachfördern, bis entweder der Sensor belegt ist oder nach X Sekunden mit einer Meldung a lá "Da kommt nix. ist überhaupt was auf der Rüttelbahn?" anhalten.

Nachtrag:

Das muss natürlich auch direkt nach dem Einschalten funktionieren. Ich denke ich werde einfach ein flag dafür hernehmen. Da hätte ich noch ein paar von frei.

Gruß

Jörn

Moin,

a prospos TIMER-Abfrage: Gibt es eine Möglichkeit abzufragen, ob ein TIMER gerade aktiv ist? In den System-Variablen hab ich nichts gefunden - ich hab allerdings auch keine Liste aller System-Variablen. Als workaround würde mir nur sowas einfallen:

! check if timer is active

R[1] = $TIMER[1].$TIMER_VAL

WAIT 0.01sec

R[2] = $TIMER[1].$TIMER_VAL

IF (R[1] <> R[2]) THEN

F[1] = ON

ELSE

F[1] = OFF

ENDIF

Gruß

Jörn

Ich hab die nicht definiert. Die Signale stehen aber mit DO[25] bis DO[27] in der Config drin. Ich dachte die wurden vom System automatisch vergeben. Nach Deinem Post und einem Fragezeichen über dem Kopf hab ich mal den Telefonjoker eingesetzt.

Des Rätsels Lösung:

Der (ehemalige) Kollege hat die DOs in der Config eingetragen, sie aber im I/O nicht gemapped. Nachdem ich das Mapping nachgetragen habe, werden sie nun auch angezeigt.

Moin,

unter MENU > SYSTEM > Config sind die Signale signal to set in auto / T1 / T2 mode DO[...] zu finden. Wo kann ich mir denn den aktuellen Zustand dieser Ausgänge anschauen?

Das Set if INPUT SIMULATED DO[...] z.B. habe ich unter MENU > I/O > Cell Intface gefunden, die signal to set in auto / T1 / T2 mode DO[...] sind aber weit und breit nicht zu sehen, auch in allen anderen Übersichten (Digital, UOP, ...) nicht.

CRX-20iA/L

$VERSION: V9.40244

Nachtrag:

Ich lese gerade in der Anleitung "If the three-mode switch is set to AUTO mode, a specified DO is turned on." Der CRX hat allerdings keinen Mode-Switch in Form eines Buttons. Mag es vielleicht daran liegen?

Vielen Dank.

Gruß

Jörn

Guten Morgen,

für alle Leseratten hier:

Auf der Seite https://www.motoman.com/en-us/…ing/product-documentation gibt es diverse Anleitung zum kostenlosen Download.

Gruß

Jörn

Zitat von halbesYoyo

CRX (Neues Programm) -> RoboGuide & PC

CRX -> PC: In FileZilla Drag'n'drop <progname.tp> von md: nach Backup-Ordner

PC -> RoboGuide: Rechtsklick [Dateien] -> [Hinzufügen] -> <progname.tp>

RoboGuide -> RoboGuide: [Dateien] -> Rechtsklick <progname.tp> -> [Load]

RoboGuide -> PC: [Programme] -> Rechtsklick <progname.tp> -> [Speicher] -> [Text (.LS)]

Zu dem Thema hat mir der Technische Support einen kleinen Workaround mitgeteilt:

CRX (Neues Programm) -> RoboGuide & PC

RoboGuide: Ein neues, leeres Programm mit dem gleichen Namen wie auf dem Roboter in RoboGuide erzeugen.

CRX -> RoboGuide: [Programme] -> Rechtsklick <progname.tp> -> [Import] -> [Von Roboter]

RoboGuide -> PC: [Programme] -> Rechtsklick <progname.tp> -> [Speicher] -> [Text (.LS)]

Moin,

Für unser aktuelles Projekt arbeite ich mit einem CRX mit Tablet und RoboGuide. Das ständige Umwandeln zwischen TP und LS und hin- und herkopieren zwischen Roboter, PC und RoboGuide ist alles andere als Intuitiv oder benutzerfreundlich. Man muss höllisch aufpassen die Datei in der richtigen Reihenfolge umzuwandeln und von A nach B nach C zu importieren / exportieren / kopieren oder speichern. Sonst hat man da ganz fix Inkonsistenzen drin.

Ziel ist es alle Programme auf dem gleichen Stand zu haben, d.h. auf dem CRX, in RoboGuide und (als Backup idealerweise als LS) auf dem PC. Die in RoboGuide unter [Programme] angezeigten TP-Programme sind nicht als separate Dateien irgendwo im Projekt unter My Workcells sichtbar. Deshalb kann man nicht einfach den Ordner irgendwo anders hin kopieren. Aus dem Grund hätte ich gerne das separate Backup (als LS) auf dem PC.

Aktuell mache ich es so:

RoboGuide (Neues und bestehendes Programm) -> CRX & PC

RoboGuide -> PC: [Programme] -> Rechtsklick <progname.tp> -> [Speicher] -> [Text (.LS)]

RoboGuide -> CRX: [Programme] -> Rechtsklick <progname.tp> -> [Export] -> [Zu Roboter]

CRX (Bestehendes Programm) -> RoboGuide & PC

CRX -> RoboGuide: [Programme] -> Rechtsklick <progname.tp> -> [Import] -> [Von Roboter]

RoboGuide -> PC: [Programme] -> Rechtsklick <progname.tp> -> [Speicher] -> [Text (.LS)]

CRX (Neues Programm) -> RoboGuide & PC

CRX -> PC: In FileZilla Drag'n'drop <progname.tp> von md: nach Backup-Ordner

PC -> RoboGuide: Rechtsklick [Dateien] -> [Hinzufügen] -> <progname.tp>

RoboGuide -> RoboGuide: [Dateien] -> Rechtsklick <progname.tp> -> [Load]

RoboGuide -> PC: [Programme] -> Rechtsklick <progname.tp> -> [Speicher] -> [Text (.LS)]

Ich bin mir sicher, daß das auch etwas weniger Umständlich geht. Am liebsten wäre mir ein Button, mit dem ich auf Knopfdruck alle Dateien auf dem CRX, in RoboGuide und dem Backup-Ordner synchronisieren kann. Gefunden habe ich so einen aber bisher nicht. Vielleicht hat ja jemand einen Tip für mich?!

Danke schonmal.

Gruß

Jörn