Beiträge von rmac

    Hallo zusammen,


    hat irgendjemand eine Idee wo bzw. wie ich an Unterlagen zum Bosch Scara SR800 komme ? Insbesondere Handbücher zur Programmierung oder dgl. wären wichtig.


    Vielleicht hat jemand auch Originale die er veräußern möchte oder mir (gegen Geld) ausleihen kann damit ich Kopien machen kann.


    Bin für jeden Tipp dankbar.... :merci:
    Danke und Gruß
    Rainer

    Hallo,


    RapTool, kenn ich nicht ! :huh:
    Auch googlen hat nichts gebracht ...


    Wo krieg ich das denn her ?


    Thx für Infos und Gruß
    Rainer

    Hallo Stefan,


    ich hab da mal was vorbereitet....


    Vorschlag 1: Synchronisieren der Tasks über dig. Ausgänge
    Laut Doku macht WaitUntil ein wiederholtes Abfragen (Polling) der Bedingung (nur) ca. alle 100ms. Wenn man die Synchronisierung über WaitDO, also durch Setzen/Rücksetzen eines digitalen Ausgangs bewerkstelligt, wird die Abfrage mit Interrupt-Geschwindigkeit erledigt. Ist auf jeden Fall (ein wenig) schneller und eleganter... Ein weiterer Vorteil ist, dass man auf der IO-Seite am TeachPanel anhand des Ausgangs direkt sehen kann ob und wann die Bilderkennung aktiv ist.


    Vorschlag 2: Triggern der Vision Task direkt nach Verlassen des Kamerasichtfeldes
    Durch Teachen eines Zwischen(Trigger)punktes kann man den nächsten Erkennungsvorgang direkt nach Verlassen des Kamerasichtfeldes auslösen, indem man an dieser Position (quasi im "Vorbeifliegen") den dig. Triggerausgang setzt. (Siehe Skizze und Code bzw. Doku. zu MoveLDO bzw. MoveJDO)



    Vorschlag 3: Verschiebung von Bewegungsabläufen über Program Displacements realisieren
    Nach Möglichkeit sollte man bei der Verschiebung (hier DX,DY) von kompletten Bewegungsabläufe die Manipulation von Robtargets, Pos usw. vermeiden. Besser ist die Verwendung von Program Displacements (siehe Code). Das Gleiche gilt für die Rotation von Achsen, d.h. man könnte (uns sollte) das auch bei der Korrektur der Greiferrotation einsetzen (statt die Tooldaten zu manipulieren!). Hab ich hier aber nicht umgebaut...(schau diesbzgl. mal in die Rob-Doku)


    Vorschlag 4: Diverse kleinere Programmänderungen zur Verbesserung der Übersichtlichkeit und Fehlersuche
    z.B. Statuscodes des Vision Systems u.a. (siehe Code)



    Hier nun die Programmausschnitte. Ist noch nicht ganz vollständig, sollte aber als Basis für weitere "Experimente" ausreichen. :)
    ACHTUNG: logischerweise alles ungetestet und OHNE Gewähr, also auf eigene Gefahr!


    VisionTask:



    Hier der Ansatz für die MainTask:


    Wie gesagt, ich weiß nicht ob das so funzt, denke aber es sollte gehen...
    Nicht vergessen den Triggerpunkt zu teachen, das doVisionActive-Signal zu definieren und ansonsten viel Spaß beim Experimentieren.


    Gruß
    Rainer

    Hallo Stefan,


    noch ein Nachtrag:
    Man könnte die VisionTask dahingehend optimieren, dass die Initialisierung nur einmal beim Systemstart und nicht bei jeder Messung ausgeführt wird, aber wenn du sonst keine Möglichkeiten zur Anpassung/Parametrierung des Erkennungsprozesses auf dem VisionSystems hast, kannst du zeitlich nicht viel dran machen.... :(


    An dem Programm insgesamt ließe sich schon durchaus einiges ändern :pfeif:
    Hier z.B. ein Vorschlag für haupt() in der MainTask:
    (ACHTUNG: alles ungetestet und OHNE Gewähr !!!!)


    Man könnte noch andere Dinge weiter vereinfachen und besser strukturieren, nur dafür müsste man natürlich die anderen Procedures entsprechend anpassen.


    Noch ein Tip zum Ablegen der verschiedenen Teile:
    Du benutzt zum Aufruf der unterschiedlichen Ablagebewegungen diesen großen Case-Konstrukt (TEST/ENDTEST). Ich würde für jedes Teil eine Ablageroutine schreiben und diese dann über den Namen aufrufen. Ist viel übersichtlicher und pflegbarer..... :supi:
    Beispiel:


    Der Aufruf der Ablage in Saegevorgang() könnte dann in etwa so aussehen:

    Code
    PROC Saegevorgang()
        WaitTime 0;
        Greifer1.tframe.rot:=[1,0,0,0];
        MoveL HOMEPOS,vmax,fine,Greifer1\WObj:=wobj0;
        FindItem:=TRUE;
        %CAblage_Procs{TeileNr}%;
        GreiferAuf;
        MoveL HOMEPOS,vmax,fine,Greifer1\WObj:=wobj0;
     ENDPROC


    Gruß
    Rainer

    Stefan,


    scheint ja zumindest vom Ablauf wie gewünscht zu funktionieren.
    Wenn ich das richtig sehe, scheint der Step 4 (ORISRep_GetReslt = Teileerkennung?) des VisionSystems () länger zu brauchen (> 2 Sek.). Das würde auch zu deiner Aussage am Anfang des Threads passen, nämlich das der Ablauf mit vorgegebener Teile-Nr. wesentlich schneller funktioniert. Da läßt sich aber wahrscheinlich von deiner Warte aus nicht viel dran drehen.... :(


    Wie sieht es denn bei den weiteren/folgenden Durchläufen aus?
    Hängt er dann auch genau so lange an der gleichen Stelle ?


    Gruß
    Rainer

    Stefan,


    übernehme mal die folgende Log-Routine in die Tasks

    Code
    PROC logWrite(string Text)
        CONST string logFileName := "HOME:run.log";
        VAR iodev AFile;
        Open logFileName, AFile \Append;
        Write AFile, Text + CDate() + " " + CTime();
        Close AFile;
      ERROR
        Return;
      ENDPROC


    und bau diese (wie vorher) in die entsprechenden Schleifen ein, also
    in der MainTask Schleife:

    Code
    logWrite("Main: " + NumToStr(Schleifenzähler,0));


    und in der While Schleife in der VisonTask

    Code
    logWrite("Vision: " + NumToStr(nStep,0));


    Nach dem Ausführen steht das Ergebnislog dann in der Datei "run.log".
    Kopier das mal aus der Steuerung und poste den Inhalt hier als Antwort. Mich würde mal interessieren was dabei so rauskommt.....


    Gruß
    Rainer

    Hallo Stefan


    bau mal in die (NEU-)Schleife in der MainTask folgendes ein:
    TPWrite "Main: " + NumToStr(Schleifenzähler,0) + " " + CTime();


    und in der While Schleife in der VisonTask
    TPWrite "Vision: " + NumToStr(nStep,0) + " " + CTime();


    schau dann mal auf dem TPanel was wann gemacht wird.


    Rainer

    Hallo,


    habe mir dein Programm jetzt mal was genauer angesehen.
    Gib doch in der NEU Schleife (am besten direkt hinter dem Label "NEU") einen Text (oder besser (Schleifen-)Zählerwert) auf dem Teachpanel aus, dann kann man wenigstens feststellen ob der ProgramCounter steht oder in der Schleife kreist.


    Bis gleich
    Rainer

    Hallo Stefan,


    also ich glaube das Problem ist das WaitDO in der GreiferAuf() Proc.
    In Haupt() wird zuerst GreiferAuf() und dann Home() aufgerufen.
    Wenn du die Zustimmtaste losläßt, dann ist der Rob noch im Wartezustand (WaitDO), zeigt aber schon den nächsten auszuführenden Befehl an (MoveL in Home()) könnte ich mir vorstellen (?). Probiers mal mit vertauschen der Befehle in GreiferAuf().


    Gruß
    Rainer

    Tach auch,


    also:
    was du da in den GreiferAuf() bzw. GreiferZu() Routinen mit WaitDO machst, ist bestimmt nicht im Sinne des Erfinders. WaitDO wartet so lange bis das entsprechende Signal (Greifer) gesetzt bzw. rückgesetzt wird (oder bis TimeOut), was aber erst im nächsten Befehl ausgelöst wird (!), das kann, glaub ich, so nicht funktionieren. Einfach mal die Reihenfolge der Instruktionen tauschen....


    Bei welcher Zeile der Rob die Zeit vertrödelt habe ich aber jetzt nicht wirklich geblickt :nocheck:
    Beschreibe bitte die Stelle etwas genauer. Wie hast du denn gemessen wieviel Zeit er wofür braucht ?


    Noch was:
    Greifer1 ist doch das Werkzeug (tool). Ich würde die Orientierung des Greifer nicht über die Manipulation der Strukturdaten machen, ist nicht so elegant (vielleicht ist es aber auch völlig genial und ich habe nur das Programm nicht geblickt :wallbash:). Das Verfahren über berechnete Robtargets halte ich für besser (und nachvollziehbarer).


    Gruß
    Rainer

    Hallo Stefan,


    Zitat

    Die leute von Isra sagten mir es könnte daran liegen das ABB die schnittstelle z.B. 2 sek. geöffnet hält und danach schließt und diese nach einer gewissen Zeit wieder öffnet. Kann das sein ?


    Klingt für mich zwar nicht unbedigt logisch, unmöglich ist aber (fast) nichts. (Ich habe es auch geschafft die S4C mit serieller IO "bluescreen-mäßig" abzuballern)


    Hier ein bisschen Code aus einem damaligem Projekt:


    Insbesondere das Löschen des SIO-Buffers (ClearIOBuff) kann manchmal Wunder wirken.
    Auch das Schließen des Kanals im (Timeout-)Fehlerfall nicht vergessen! (=sonst böse Falle).
    Je nachdem in welchem Format das VisionSystem die Kommandos/Parameter erwartet, könnte man ggfls. auch mit angehängten CR und/oder LFs experimentieren.


    Zitat

    hat aber leider nicht funktioniert Fehlermeldung war: 40505 Kann nicht öffnen Sio1: Raise Code: Err_Fileopen=1015


    Das würde auf einen generellen Fehler bei den SIO-Parametern (Baudrate, Handshake, etc) hindeuten, ist aber auszuschließen wenn die ser. Kommunikation über diesen Kanal sonst prinzipiell funktioniert. Möglicherweise ist der Kanal aber auch schon geöffnet, allerdings weiß ich nicht ob das doppelte Öffnen diese Fehlermeldung provozieren würde. Am besten die komplette Kommunikation zw. Roboter und Vision erstmal in einer Proc isolieren (Kapseln mit Open/Close) und testweise in der Maintask laufen lassen (also alle anderen Tasks beenden um Multitasking Probleme auszuschließen). Vielleicht bringt das mehr Hinweise.


    Gruß
    Rainer


    Nachtrag:
    Eine weitere Fehlerquelle könnte die Baudrate sein, deshalb erstmal langsam starten (z.B.: 9600 Baud) und wenns funktioniert langsam steigern.

    Hallo,
    ich habe im Laufe des letzten Jahres mal zwei Vision-Systeme (einmal Matsushita und einmal Eigenbau) seriell mit der S4C gekoppelt, allerdings nicht mit Multitasking, sondern in der Main-Task.
    Ich hatte da auch so meinen "Spaß" mit, aber irgendwann funktionierte es....


    Prinzipiell kann man den seriellen Kanal schon offen lassen indem man die entsprechende iodev Variable in einem globalem Modul deklariert, beim Start des Programms einmal initialisiert usw.
    Ich habe damit aber keine guten Erfahrungen gemacht (mangelnde Stabilität) und könnte mir auch vorstellen, dass das nicht die Lösung des Problems ist. Um die Problematik einzugrenzen und herauszufinden was wann passiert, sollten Sie versuchen den zeitlichen Ablauf zu analysieren, indem Sie den Prozeß in kleinere logische "Häppchen" zerlegen und nach jedem (Teil-)Schritt eine Meldung mit Zeitangabe auf dem TeachPanel oder in eine Logdatei ausgeben. Dann kann man weitersehen....


    Wenn die Koordinatenübergabe reproduzierbar(!) bei 1,5 Sekunden und die Objekterkennung bzw. -verifikation bei 8,5 Sekunden liegt, dann würde ich mich zunächst mal mit dem Vision-System beschäftigen... :wink:


    Gruß
    Rainer

    Hallo Norbert,


    auch auf die Gefahr hin, dass ich dich missverstehe:
    Ich meinte eigentlich alle 300 robtargets (bzw. Befehle mit robtargets) wenn möglich zu markieren und dann das Suchen/Ersetzen (durch den geschickten Einsatz regulärer Ausdrücke ;)) auf die gesamte Markierung anzuwenden, also alle 300 robtargets mit einem (oder zwei) Durchläufen zu ändern, nicht 300mal einzeln...


    Wenn du das auch so gemeint hast, dann bitte meine Antwort ignorieren.... :lipsrsealed:


    >Achskonfiguration nur für die Achse 1 abschalten
    wüsste nich dass das geht...


    Gruß
    Rainer

    Hallo,


    um die Achskonfiguration (oder Teile davon) innerhalb eines robtargets auf einen bestimmten, festen Wert zu setzen, würde ich versuchen mit einem Editor der Suchen/Ersetzen mit regulären Ausdrücken unterstützt (UltraEdit?), den entsprechenden Wert dort einzutragen.
    Da reguläre Ausdrücke etwas "gewöhnungsbedürftig" sind, muß man sich allerdings damit zunächst ein bisschen beschäftigen (...mal danach googlen).


    Gruß
    Rainer