Beiträge von rmac

Hallo,

habe mal bei Amazon nach "roboter gesellschaft" gesucht und bin auf dieses Buch:
https://amzn.to/2M9Ps1N
gestoßen.

Im Umschlagtext steht:

Zitat

[...]Die vorliegende Studie wurde von der Projektgruppe "Robotik" der Europäischen Akademie zur Erforschung von Folgen wissenschaftlich-technischer Entwicklungen Bad Neuenahr-Ahrweiler GmbH erarbeitet.[...]

Google ergab daraufhin:
http://www.europaeische-akadem…rogramm/2005_november.pdf

Dort findest du auf Seite 21 die Forschungsgruppe. Vielleicht findest du in dem o.g. Buch ja noch Hinweis auf weitere Literatur oder du versuchst die Profs ausfindig zu machen und bittest die um Literaturverweise...

HTH und guten Rutsch :party020:
Rainer

Hallo totalfuchs,

wie du optionale Parameter mit dem TeachPanel hinzufügst, kann ich dir garnicht sagen, da ich so etwas über einen Editor programmiere und nicht mit dem TP aber irgendwie wirds schon gehen...

Versuch einfach den BackwardHandler leer zu lasssen, also z.B. so:

PROC BspOhneBackward ()
  ! hier Proc Instruktionen ....
  MoveL ...
  ! blablabla 
BACKWARD
  ! hier nix schreiben
ENDPROC

Gruß
Rainer

zabri,

you should stick to English language , at least if you ask questions in this forum, since you won't get any reasonable response if you use automated translation resources in this case. Especially concerning technical questions it's hard to understand the intended meaning of these *translations* and you will probably get some laughs here instead of useful answers.

Merry Xmas to you and your family
Rainer

ja genau, da schließ ich mich doch gerne an

	frohes Fest und gutes Neues,
	haltet euch senkrecht
	und nächstes Jahr wird alles (noch viel) besser...

Gruß :ylsuper:
Rainer

totalfuchs,

deklariere doch die Übergabeparameter als optional und verwende die Parameter nur dann wenn diese auch übergeben wurden, ansonsten Standardwerte (ist allerdings mehr Schreiberei), also ungefähr so:

PROC Move_RS( \num nArgPos_RS  \num nArgRampeA  \num nArgDrehzahl   \num nArgRampeB)
! hier Deklaration mit Standardwerten
var num nPos_RS := 12; 
var num nRampeA := 34;
var num nDrehzahl := 56;
var num nRampeB := 78;


! Parameter verwenden wenn welche übergeben wurden
if Present(nArgPos_RS) nPos_RS := nArgPos_RS; 
if Present(nArgRampeA)  nRampeA := nArgRampeA;
if Present(nArgDrehzahl) nDrehzahl := nArgDrehzahl;
if Present(nArgRampeB) nRampeB := nArgRampeB;
...

Hat u.a. auch den Vorteil, dass man nur die Parameter selektiv übergeben kann, die von den Standardwerten abweichen, also z.B. nur die Drehzahl oder so...

Zu der Sache mit der Rückwärtsfahrt steht in der Doku:

Zitat

A procedure with no backward handler cannot be executed backwards. A procedure
with an empty backward handler is executed as "no operation".

Würde ich jetzt so interpretieren, dass eine Proc ohne BackwardHandler sowieso nicht rückwärts ausgeführt werden kann (!) bzw. dass nichts passiert wenn man den BackwardHandler einfach leer läßt. Probier's doch einfach aus...
Gruß und frohes Fest
Rainer

Hallo,

ich kenne KUKA (leider) garnicht und kann dir dazu nichts sagen, aber ich würde das bei S4C+ so machen:

Auf der Bahn zum Zielpunkt einen Zwischenpunkt setzen und und diesen (je nach Anwendungsfall) mit MoveLDO, MoveJDO oder MoveCDO und nicht zu kleiner Zone "überfahren". Beim Überfahren des Zwischenpunktes dann den Ausgang setzen (siehe Doku zu den MoveXDO Befehlen!!!)
Am Zielpunkt dann mit WaitDI das Gegensignal abfragen und dann ggfls. weitermachen...

Hängt aber natürlich von den örtlichen Gegebenheiten ab sich das so realiseren läßt.

Gruß
Rainer

Schau mal hier:
http://www.angusj.com/delphi/textdiff.html
ist schön klein und handlich.

Zitat

Hab schon jede Menge Programme aus dem Netz ausprobiert die aber alle nicht
wirklich gut waren.

...dann wäre es vielleicht nicht schlecht wenn du schreiben würdest welche Programme nicht wirklich gut waren, dann braucht man dich ja auf diese nicht mehr aufmerksam machen...

Gruß
Rainer

Also ich würde auch die zweite Version (mit Array) bevorzugen.
Allerdings würde ich (bei beiden Versionen) weitestgehend mit Konstanten arbeiten. Ist zwar mehr Schreiberei und auf den ersten Blick auch nicht wirklich übersichtlich, aber spätestens der nächste Kollege der an diesem Projekt arbeiten muß wird es einem danken...

Also etwa so:

CONST num CMaxItems:=3;
  CONST num CItemNo4711:=1;
  CONST num CItemNo4712:=2;
  CONST num CItemNo4799:=3;
  
  CONST num CIN4711_Param1:=15;
  CONST num CIN4712_Param1:=19;
  CONST num CIN4799_Param1:=22;


! Das geht leider bei Persistenten nicht, da bei PERS keine Deklaration mit bezeichneten Konstanten erlaubt ist
!  PERS num nOutPut_Array{CMaxItems}:=[CIN4711_Param1,CIN4712_Param1,CIN4799_Param1];  <- Fehler !!!
! aber bei VARs gehts
  VAR num nOutPut_Array{CMaxItems}:=[CIN4711_Param1,CIN4712_Param1,CIN4799_Param1];
! wenn's PERS sein muß, dann nur so:
  PERS num nOutPut_Array{CMaxItems}:=[15,19,22];


! in der "alten" Version sähe es dann so aus:
   TEST nMould_No
     CASE CItemNo4711 : nOutput := CIN4711_Param1;
     CASE CItemNo4712 : nOutput := CIN4712_Param1;
     CASE CItemNo4799 : nOutput := CIN4799_Param1;
     DEFAULT: Stop;
   ENDTEST

Ein Nachteil der Array-Methode ist jedoch das die Indizierung lückenlos sein muß und bei Eins beginnt. Wenn z.B. die Teile/Artikel/Item-Nummer von einem übergeordneten Prozessleitrechner in ASCII-Form ("ABC-221244", "ADB-469809", "XYZ-909850", usw.) geliefert wird, oder als Ganzzahl mit großen Lücken (z.B.: 0, 23, 567, 698977, usw.) dann müsste man diese Nummer erst wieder in einen fortlaufenden Index konvertieren und dann kann man schon fast wieder besser mit TEST bzw. IF THEN ELSE arbeiten.
Bei einer großen Anzahl von Varianten und/oder bei großen Parametersätzen würde ich aber ohnehin alles in eine externe Konfig.-Datei packen die vom Rob gelesen wird und mit einem (Text-)Editor angepasst werden kann.

Schönes WE noch
Rainer

Zitat

Schade, dass ABB so wenig Vertrauen in Anwendungsprogrammierer hat.

Ich denke das hat wahrscheinlich garnichts mit Vertrauen zu tun, sondern vielmehr mit Sicherheit/Stabilität des darunterliegenden Betriebssystems. Den Aufwand, den die System-Programmierer betreiben müssten um diese Sicherheit/Stabilität aufrecht zu erhalten während zeitgleich irgendwelche Anwendungen wichtige(!) Systemparameter ändern, ist nicht zu unterschätzen. Obwohl ich bekennender Neustart-Hasser bin, habe ich durchaus Verständnis für diesen Systemprogrammierer-Standpunkt: es macht die Sache halt einfacher und schließlich kann man durch einen Neustart jede Menge potenzieller Fehlerquellen ausschließen.

Viele werden sich vielleicht noch an Win95-Zeiten erinnern, als man alle Nase lang den Rechner neu starten musste sobald man irgendwo eine Einstellung geändert hatte. Das haben die in den neueren OS-Versions mittlerweile ganz gut in den Griff gekriegt. Man muß XP zwar auch noch einigemale neu starten, aber das hält sich insgesamt in Grenzen. Immerhin kann man bereits einige wichtige Hardware-Parameter (Netzwerkkarten etc.) ohne anschließenden Neustart ändern.
Das alles ging aber auch erst nachdem Microsoft beim Übergang zu Windows-NT (relativ) radikal das alte Treiberkonzept über Board geworfen hatte usw....

Letztlich, denke ich, ist es einfach ein Geldfrage wieviel Zeit man (ABB) in System-Programme investiert um den Komfort zu steigern. Meiner Meinung nach ist der Markt dafür schlichtweg zu klein. Das bedeutet, eine Besserung ist erst in Sicht wenn ABB die Verkaufszahlen von Microsoft erreicht.
Da müssen wir also nur noch (ein bisschen) warten....

Gruß
Rainer

@mod-poser,

Zitat

Wenn ich die Fehlernummer erst nach einem RAISE behandle, ist es doch aber so,
daß ein darauffolgendes RETRY den Programmzeiger in der Routine des behandelnden
Errorhandlers auf den Prozeduraufruf stellt, aus dem der der RAISE-Befehl letzendlich, wennauch
über mehrere Prozeduraufrufe und Rücksprünge, gekommen ist.

Ich weiß nicht ob ich dich da richtig verstehe, deswegen laß es mich mal so ausdrücken:
RETRY stellt den Programmzeiger in der Routine des behandelnden Errorhandlers auf den Prozeduraufruf zurück, aus dem der letzte RAISE-Befehl gekommen ist, d.h auf die letzte Routine in der Kette der (Fehler-)weitergebenden Routinen bevor RETRY aufgerufen wird.
RETRY springt also nicht auf den Anfang der ersten, ursprüngliche Routine die den Fehler ausgelöst hat (aber ich denke mal das hast du auch nicht gemeint...)

Zitat

Wenn man dies geschickt plaziert, weit genug mit RAISE zurückspringen und dann nochmal versuchen,
kann man sich jede Menge Programmiererei ersparen.

Ich denke mal man hat nicht wirklich mehr Arbeit wenn man das vernünftigt mit Funktionen und Rückgabewerten programmiert. Sicherlich könnte ich mir den einen oder anderen Fall vorstellen, bei dem man da ein paar Zeilen spart, aber spätestens wenn es um Fehleranalysen, Dokumentation und dgl. geht, ist man ohnehin meistens gezwungen Statuswerte weiterzugeben, übergeordnet auszuwerten oder sonst was.
Wie auch immer, halte ich die begrenzte/vorgegebene Anzahl der Wiederholungen bei RETRY nach wie vor für die größte Einschränkung.
Ich könnte einen derartigen Kontrollverlust in meinen Programmen einfach nicht hinnehmen...

good night
Rainer

jungs,

in diesem Zusammenhang (Suchen etc.) gibt es eh nicht besonders viele sinnvolle Anwendungen für RETRY, denke ich, zumindest würde ich es ungerne einsetzen, weil (Zitat Doku):

Zitat

If the maximum number of retries (4 retries) is exceeded, the program execution stops
with an error message. The maximum number of retries can be configured in System Parameters (System miscellaneous)

Ausserdem funzt RETRY nicht wenn der Fehler über RAISE ausgelöst wurde. (Ja gut, damit könnte man noch leben...)

Nach dem Motto "Wer hat an der Uhr gedreht, ist es wirklich schon so spät ...?" steht man dann vor der Kiste und wundert sich warum "unser Liebling" denn schon nach 4 Versuchen aufgegeben hat...
Gut, der ein oder andere mag sagen: "Toll, dann kann ich das doch über die System-Parameter einstellen!"
...jau, aber spätestens wenn man an verschiedenen Stellen unterschiedliche Wiederholungsversuche braucht ist "Ende im Gelände", von dem "System-Parameter umgestellt -> dann Neustart"-Generve mal ganz abgesehen. Nee, danke.

Hey, mir fällt gerade auf, dass dieser Smiley den Zyklus "System-Parameter ändern -> Neustart" ziemlich gut versinnbildlicht.
Obwohl der ist auch nicht schlecht...

In diesem Sinne, schönen Feirabend noch...
Rainer

Hallo noob,

hier ein Ausschnitt aus meinem Fundus, vielleicht als Anregung.
(Habe ich schnell zusammengekürzt, deshalb OHNE GEWÄHR!)

FUNC bool doMySearch()
    CONST num CMaxRetries:=3;
    VAR num nRetries:=0;
    VAR bool bRslt:=FALSE;


    WHILE (nRetries < CMaxRetries) AND (NOT bRslt) DO
      ! Hier Suchen initialisieren, d.h.
      ! an den Anfang der Suchposition fahren usw.
      
      Incr nRetries;
      bRslt := TRUE;
      SearchL ...;
      
      ! hier ggfls. Suchergebnis(se) auswerten wenn bRslt immer noch TRUE
      ! IF bRslt THEN ... ENDIF
    ENDWHILE
    RETURN bRslt;
    
  ERROR
    IF (ERRNO=ERR_WHLSEARCH) THEN
      bRslt:=FALSE;
      TRYNEXT;
    ELSE
      ! hier ggfls. weitere Fehlerbehandlung
      RAISE;
    ENDIF
  ENDFUNC

Gruß
Rainer

Hallo Noob,

sorry, aber irgendwie kann ich die Syntax deines Programmausschnittes nicht nachvollziehen:

Zitat

Variablen bsuchenI.O und bsuchenN.IO ...
var=bsuchen ...
IF bsuchenniO=true then ...

Zitat

die Variable wird am Anfang der Procedure deklariert, aber nirgens einen Wert zugeordnet...

Ein Wert muß auch nicht zwingend zugewiesen werden (Zitat Handbuch):
"Variables with value types may be initialised (given an initial value). The expression
used to initialise a program variable must be constant. Note that the value of an
uninitialized variable may be used, but it is undefined, i.e. set to zero."
d.h. in deinem Fall ist die Variable (wenn nicht anders initialisiert oder zugewiesen) also FALSE.

Selbst wenn es eine entsprechende globale Variable mit gleichem Namen geben würde, die intern zur Verarbeitung von SearchL o. dgl. genutzt wird, würde man auf diese Variable in der Procedure nicht zugreifen können sobald eine lokale Variable gleichen namens in der Proc deklariert wird, da diese im lokalen Kontext (Scope) bevorzugt werden würde.

Zu guter Letzt halte ich es für recht unwahrscheinlich, dass die RAPID-Entwickler (Schweden ?) für eine derartige Variable einen deutschen Namen verwenden würden. (Obwohl... weiß jemand was "Suchen" auf Schwedisch heißt ?)
BTW: Ich finde die "Main() <-> Haupt()" Benennung ist schon ein ziemlich krampfhaftes Zugeständnis.

Gruß
Rainer

Ich würde annehmen das Ausgang 2 im Ar.... ist.
Du hast doch noch genug Ausgänge frei (?), probier doch mal 4,5, usw.
Was passiert'n da ?

keine Reaktion auf dem Panel oder nur bei dem Ventil ?
Ändert sich denn der Status im Panel auf "1" oder bleibt der auf "0" ?

Wenn der Status sich auf dem Panel ändert, aber das Ventil nicht schaltet, dann mal versuchen den Ausgang mit einem Multimeter "durchzuklingeln" (vorausgesetzt das Ventil ist OK, aber du sagtest ja auf einem der anderen Ausgänge funzt das Ding)

oha...

also:
auf dem TeachPanel ist auf der linken Seite/Mitte eine Taste mit zwei übereinanderliegenden, entgegengerichteten Pfeilen. Wenn du diese Taste drückst, gelangst du auf die EA-Seite.
Im Menu "Ansicht" wählst du Punkt 4 ("Dig. Ausgänge") und bekommst anschließend alle dig. Ausgänge mit Namen und Wert (Status) tabellarisch angezeigt, darunter auch dein "DO10_2" (hoffentlich)
Mit den Pfeiltasten wählst du den gewünschten Listeneintrag aus und kannst nun den Schaltzustand dieses Ausgangs direkt mit den Tasten unterhalb von "0" und "1" (unten links), aus- bzw. einschalten.

Zitat

Irgendwas weiter noch hinzufügen als Optionen oder Einstellungen muß ich aber nicht oder?

Nicht das ich wüsste, sollte alles so funktionieren....

Zitat

Aber mal ne ganz andere Frage: gibt das eigentlich eine schöen Seite oder ein Buch wo solche Sachen u.a. in verständlicher Sprache drin beschrieben sind? Unsere 2 Studenten die sich schon seit einigen Wochen mit der Bedienungsanleitung beschäftigen sind nicht wesentlich schlauer als vorher....

Ist mir nicht bekannt, das will aber nichts heißen.
Es gibt mit Sicherheit bessere Bedienungsanleitungen als die von ABB, aber auch jede Menge schlechtere...
Prinzipiell kriegt man schon alles raus wenn man die Zeit zum Lesen und Spielen hat.
Wenn ihr Geld und Zeit habt, kann auch ein (Grund-)Kurs Roboterbedienung bei ABB nicht schaden.
Ich war zwar selbst nie bei einer Schulung, ich kenn aber einen der da war und der hat mir die Grundzüge erklärt.
Der Rest ist Lesen und Ausprobieren...

Gruß
Rainer

Hi,

läßt sich das Signal denn direkt auf der EA-Seite im Panel schalten (also nicht programmiert mit "Set ...") ?
Welcher Status wird im Panel für dieses Signal angezeigt ?
Wurde die Steuerung neu gestartet (ggfls. Fehlermeldung) ?

Grüße
Rainer

Tach auch,
maddin: der Ergebnistyp der Funktion ist "num" (is ja eine Länge )

@Boot-Error:
Falls du das häufiger für Robtargets brauchst, kannst du das auch selber berechnen,
ungefähr so: (ohne Gewähr)

FUNC num RTDist(robtarget rt1, robtarget rt2)
    RETURN Sqrt(Pow(rt2.trans.X - rt1.trans.X, 2) +
                Pow(rt2.trans.Y - rt1.trans.Y, 2) +
                Pow(rt2.trans.Z - rt1.trans.Z, 2));
  ENDFUNC

oder noch einfacher: (hab ich Depp gerade selber gemerkt )

FUNC num RTDist(robtarget rt1, robtarget rt2)
    RETURN Distance(rt2.trans, rt1.trans);
  ENDFUNC

Gruß
Rainer

Zitat

Das erfüllt mich mehr als das pure denken an Geld oder der Drang, woanders zu sein....

...hätte man besser kaum sagen können...

Hallo Elias,

vorausgesetzt man gewichtet die 6 Vorschläge deiner "ehrlichen Umfrage" gleichwertig und bildet diese auf die Gesamtzahl der beschäftigten Roboterprogrammierer ab, implizierst du mit deiner Vorschlagsliste, dass zwei Drittel aller Roboterprogrammierer geldgeile Alkoholiker mit Eheproblemen sind...

Da ich selbst nur wenige Roboterprogrammierer kenne, gehe ich zunächst mal von einem repräsentativen Querschnitt der deutschen Bevölkerung aus und kann dir diesbezüglich leider nicht widersprechen.

Ich schließe daraus messerscharf:
da ich mich selbst nicht zu dieser 2/3-Gruppe zähle und ich auch (meistens) nicht totunglücklich in meinem Job bin, muß ich wohl zu dem anderen Drittel gehören.
...und das soll auch weiterhin so bleiben.

Gruß
Rainer