Positionen anhand von GI

[Noob]

Servus,

weiß jemand, wie ich elegant anhand unterschiedlicher Formatnummern (GI)  unterschiedliche Robtargets anfahren kann?
Oder muß/kann ich das so schreiben, dass ich n+1 If-Instruktionen verwenden muß, quasi der lange Schreibweg?:


IF GI1=10 then
MoveJ ......
ENDIF
IF GI1=11 then
MoveL ......
ENDIF
IF GI1=12 then
MoveJ ......
ENDIF
......

 

[rmac]

Hallo Noob,

ich weiß zwar nicht was du unter GI-Nummern (?) verstehst, aber prinzipiell kann man das auch über ein Array (Feld) von RobTargets lösen.

Also in etwa so:

Code:

  CONST robtarget rtP1:=...;
  CONST robtarget rtP2:=...;
  CONST robtarget rtPN:=...;
  CONST robtarget rtPosArray{3}:=[rtP1, rtP2, rtPN];

  ! oder auch direkt deklariert, d.h. ohne vorherige Dekl. der Einzelpos.
  CONST robtarget rtPosArray{3}:=[[...],[...],[...]];

  ! und dann so aufrufen:
  MoveL  rtPosArray{GI}, ....

Ist aber nur dann sinnvoll, wenn deine GI-Nummerierung möglichst fortlaufend ist und möglichst bei 1 beginnt, sonst wird's aufwändiger bzw. problematisch (könnte man lösen über Lookup/Hash-Tabelle von GI auf RobTarget-Index, blablabla...)
Vergleiche hierzu auch folgendes Posting:
http://www.roboterforum.de/roboter-forum/index.php?topic=1286.0

Das Gleiche gilt wenn unterschiedliche Bewegungen (MoveL, MoveJ, ...) und/oder variable Bewegungsparameter pro Bewegung notwendig sind (Zone, Speed, etc.)
Dann muß man für jeden Parameter ein gleichlanges "paralleles" Array mit den entsprechenden Werten pflegen und beim Aufruf der Instruktion einsetzen.
Alternativ (und besonders elegant) ist hier der Einsatz von benutzerdefinierten Datentypen (siehe in Doku unter RECORD/ENDRECORD) zu bevorzugen, d.h. man definiert einen eigenen Datentyp, der sämtliche benötigten Parameter enthält und deklariert dann ein Array dieses Datentyps: jedes Element des Feldes enthält dann einen kompletten Parametersatz...

Aber Achtung, soweit ich mich erinnern kann (!), muß für benutzerdefinierte Datentypen die Software-Option "Developer Functions" installiert sein (zumindest auf der S4C (?)).
Ich hab das nämlich mal fix in ein Programmkonzept mit eingebaut um dann festsstellen zu müssen, dass das ohne diese Option nicht funzt.
Das steht wahrscheinlich irgendwo im "Klitzeklitzeklein-Gedruckten"     (oder auf schwedisch  )

Gruß
Rainer

[Noob]

GI = Gruppeneingang

und merci Rainer

[rmac]

Moin,

Danke für die Aufklärung.
Hätte ich auch selbst drauf kommen können,
war nur durch den Ausdruck "Formatnummern" etwas verwirrt... 

Aber dann könnte es mit der fortlaufenden Indizierung ja funktionieren.

Gruß
Rainer

[Sven Weyer]

Hi Noob,
die Variante mit den Datenfeld haben wir auch schon so verwendet. Des weiteren könntest Du die einzelnen Bewegungen auch in Routinen verpcken und dann in Abhängigkeit des GI aufrufen.

Proc mp12()
  MoveJ...
endproc

Der Aufruf kann dann frei gestaltet werden.

%"m"+NumToStr(GI..,0)%

wäre demnach nur ein Zeile für den Aufruf.

robotic74

[Noob]

hmm die Robotic-Version gefällt mir besser, da übersichtlicher und für andere später nachvollziehbar ist.

big thx

[Noob]

Ich nochmal  @robotic,

Dein Vorschlag beruht doch auf CallbyVar oder? Kann man da tatsächlich GruppenEingänge direkt nutzen oder sollte man den Wert im GI vorher lieber in eine Variable schieben?

[Sven Weyer]

Hi Noob,
wir benutzen das oft so. Dazu ist nichts notwendig. Es ist nur eine Frage wann und wie deine Signalkonsistenz ändert.
Aber wenn Du wirklich eine Bewegung in abhängigkeit der aktuellen Situation durchführen möchtest ist das eine Möglichkeit.

noch ein Beispiel:
%"r_"+NumToStr(giTypecode,0)+"_"+NumToStr(giVersionstyp,0)%;

so rufen wir unsere einzelnen Typen auf.
Funzt immer.

robotic74

[Noob]

oki, ich probiers mal aus 

[burlibua]

Hi Noob

rmac hat dir da schon eine tolle Lösung geboten, aber du kannst die Robtargets im Programm die im Array sind nicht direkt mit "Korpos" korrigieren. Währe vielleicht besser wenn du die Varibale zuerst umladen würdest und dann wieder zurück

Ablagepos:=Ablagepos_all[Formatnummer];
MoveL Ablagepos ...........
Ablagepos_all[Formatnummer]:=Ablageposition;

so kannst du mit Korpos die Position einfach teachen.  Ablagepos am besten als PERS definieren.

Weiters würde ich den Gruppeneingang abfragen in eine numerische Variable speichern sonst kann es passieren daß die erste Hälft des Prg als zB: Fromat 1 durchlaufen wird und
die zweite Hälfte als Format 2 wenn dazischen umgeschaltet wird.

mfG Burlibua

[rmac]

Also man kann die Elemente von RobTarget-Arrays schon mit KorPos ändern (zumindest bei der S4C (?)):
- erst in die Datenansicht für RobTargets wechseln
- dann das gewünschte Datenfeld auswählen und im Menu "Bearbeiten | KorPos" wählen
- Rückfrage mit "Ja" bestätigen
- abschließend das gewünschte Element auswählen und mit "KorPos"-Button ändern

Ob das allerdings auch bei benutzerdefinierten Daten-Arrays geht, weiß ich nicht. 
...bin jetz auch zu faul zum ausprobieren

Die CallByVar-Methode (wie von robotic74 beschrieben) ist sicherlich besser wenn man wenige Varianten und/oder komplexe Bwegungsabläufe (z.B. Fügen) abzuarbeiten hat. Ich denke so ab >15-20 Varianten (=Routinen) wirds dann aber auch irgendwann unübersichtlich.
Die Array-Methode mit RobTargets ist nur bei vielen Typen mit simplen RobTarget-Zielen von Vorteil.

Ggfls. kann auch eine Kombination von beiden Methoden sinnvoll sein:
In einem Projekt mussten bei einer Blister-Palette abhängig von der Nest-Position unterschiedliche Füge-Routinen verwendet werden um die Teile sicher in die Nester abzulegen. Die Nester sind dabei von 1..N durchnummeriert. Gelöst wurde das über ein Array{1..N} von Strings das die Namen der Füge-Routinen für die jeweiligen Nester enthält. Das hat den Vorteil, dass man eine Füge-Routine auch für mehrere unterschiedliche Nester verwenden kann (vorher mit ProgDisplacement verschieben!) und nur einige Spezialfälle gesondert programmieren muß.

Gruß
Rainer

[burlibua]

Hey Rmac

Haste recht --- bin aber zu faul um immer wieder auf Ansicht  robtargets ... zu wechseln, und außerdem haste leicht einen Fehler. Wenn du nur eine Zeile im Index verwechselst hast gleich eine die Sch... perfekt. Da tu ich doch lieber umladen da sind die Fehler begrenzt -- mann darf nur nicht da PRG vorzeitig beenden.
Ansonsten sind die Lösungen sehr gediegen.

mfG Burlibua