Strategien zur Vermeidung Programmablauf bedingter Stopps

    • Helpful

    Da unser Vertrieb immer abenteuerliche Taktzeiten verkauft versuche ich nach Möglichkeit unnötige Stopps die durch den Programmablauf entstehen, also Zonentyp „fine“ wegen Wait Intruktionen, SyncTask bei MultiMove etc. direkt von vornherein zu vermeiden.


    Konkretes nicht allzu außergewöhnliches Beispiel wäre ein MultiMove Handlings System das nicht über eine feste Schrittkette, sondern Zustandsgesteuert läuft. Sprich Bediener verschiedene Baugruppen unterschiedlich schnell vorbestücken und dadurch Ein/Ausfahrfreigaben, Kollisionsverriegelungen, Ready Signale von Prozessausrüstung, Bändern etc. etc. mal anstehen und mal nicht d.h. die Roboter mal warten müssen und mal durchfahren könnten.


    Ablauf z.B. (Pseudocode)


    Mein aktueller Ansatz (Pseudocode) weg von

    Code
    1. Move fine
    2. SetDo Schrittkettensignal an SPS
    3. WaitUntil condition 1…n
    4. SetDo Schrittkettensignal an SPS
    5. Move zone


    ist folgender Interrupt (zB bei Erreichen der VP vor Eintritt in eine Bestückstation):


    Das Ganze funktioniert zwar, wird aber von der Handhabung schnell umständlich (vorallem die Abbruchbedingung überall mit durchzuziehen da die Motion Task bei Stillstand ja immer in irgendeiner Trap hängt) und unübersichtlich.
    Gibt es einen einfacheren Weg für „selektive fine Punkte“, bzw. einen ganz anderen Ansatz? Wie handhabt ihr das?



    Grüße

    Karsten

  • Hm, WaitUntil u. WaitDi wird im Vorlauf abgearbeitet; wenn die Bedingung stimmt, dann geht er mit Zone drüber. Ist halt nur etwas undefiniert, wo er dann stehenbleibt, wenn die Bedingung NICHT zutrifft, er ist aber innerhalb der Zone. Ausser man verwendet \InPos, dann endet er immer auf dem Punkt, auch wenn man mit Zone programmiert.


    Ausgänge kriegt man mit MoveXDo bzw. komplexere Aufgaben mit MoveXSync ganz gut in den Griff. Unabhängige MultiMove-Roboter verriegeln wir hauptsächlich über programmierte Kollisionsbereiche, wo auf PERS (als taskübergreifend) zurückgegriffen wird. Der Trick ist halt da, dass man sich als Task entweder selbst blockiert oder sofort dem anderen sagt, was man gerne für sich selbst reserviert hätte.


    Man muss "in der Mitte" dann halt ein wenig mehr "fuzzy" programmieren. Nach dem "Schrittkettensignal" und vor der nächsten Bedingungsprüfung noch ein paar Bahnpunkte haben in Richtung "home" oder was immer man damit meint.


    Oder habe ich Deine Frage mißverstanden?


    Grüße,

    Michael

  • Hm, WaitUntil u. WaitDi wird im Vorlauf abgearbeitet; wenn die Bedingung stimmt, dann geht er mit Zone drüber. Ist halt nur etwas undefiniert, wo er dann stehenbleibt, wenn die Bedingung NICHT zutrifft, er ist aber innerhalb der Zone. Ausser man verwendet \InPos, dann endet er immer auf dem Punkt, auch wenn man mit Zone programmiert.

    Genau das meinte ich. Im Endeffekt möchte ich in einem sehr definierten Bereich "in letzter Sekunde" prüfen ob Bedinungen erfüllt sind und dann entspechend wenn nötig stoppen.

    Bei zB.

    Move zone Vorposition
    WaitUntil ...
    Move fine Greifposition

    habe ich doch das Problem dass die Bedingung irgendwann während der Bewegung geprüft wird, evtl erst ein paar ms später aber eben noch vor Erreichen des relevanten Bereichs TRUE geworden wäre und der Roboter dadurch auf diesem Punkt unnötig stoppt. Da fast alles bei vmax stattfindet ist "etwas undefiniert" ein Problem.



    Offtopic:


    Ausgänge triggern ist kein Thema und Kollisionserkennung auch nicht.
    Ich mache das mittlerweile zusätzlich zum Programm gerne auch auf Safety Ebene. Dank SafeMove und dessen sehr definierbaren Zonen + ProfiNet Safe zum Motion Controller kann ich zB. die Servos von Shuttles oder Drehwechseltischen in STO bzw. SS2 schalten wenn der Robi im Kollisionsbereich ist und andersrum die Zone für den Robi verbieten wenn der Servo Reglerfreigabe hat. Die neue ABB Kollisionserkennung der Kinematiken gegeneinander funktioniert mittlerweile auch bei MultiMove Independent echt gut. Selbst im Einrichtbetrieb müsste man schon kreativ werden um noch größere Kollisionen zu verursachen... schont die Nerven auf IB.

  • PseudoCode

    Code
    1. IF NOT Bedingung THEN
    2. WaitUntil Bedingung
    3. ENDIF

    Gruß Roland


    Wie poste ich falsch?

    Nachdem ich die Suche und die FAQ erfolgreich ignoriert habe, erstelle ich das gleiche Thema in mehreren Unterforen, benutze einen sehr kreativen Titel wie "Hilfe", am Besten noch mit mehreren Ausrufezeichen, und veröffentliche einen so eindeutigen Text, dass sich jeder etwas Anderes darunter vorstellt.


    Ich bin wie ich bin. Die Einen kennen mich, die Anderen können mich.

    Konrad Adenauer

  • Damit hätte ich doch wieder das Problem dass ich dank undefiniert vorlaufendem Programmzeiger nicht weiss wann er diese Bedinung prüft und das in meinem vorherigen Post beschriebene Verhalten?

    Ansonsten mache ich ja genau das in der Trap.

  • Mal so am Rande, es lässt sich auch viel Taktzeit einsparen, wenn die Zelle entsprechend konstruiert wurde.


    Eine Optimierung bei Stopp-Punkten bringt eigentlich pro Stopp-Punkt nur ein paar 100 ms ein.


    Zum Thema: Eine Möglichkeit wäre evtl. bei der letztmöglichen Position zum Bremsen ein DO zu schalten und mit der Schaltung dann zu prüfen ob gestoppt wird.

  • Du könntest mal ausprobieren, was passiert, wenn Du in der
    Bewegungsanweisung eine eigene "stoppointdata" definierst und dann auf Waituntil blabla \inpos wartest.
    Also, ich kann's nicht genau sagen, weil noch nicht auspropiert.
    Guck Dir mal "stoppointdata" im Handbuch RAPID Instruktionen, Funktionen, Datentypen an.

  • Mal so am Rande, es lässt sich auch viel Taktzeit einsparen, wenn die Zelle entsprechend konstruiert wurde.


    Eine Optimierung bei Stopp-Punkten bringt eigentlich pro Stopp-Punkt nur ein paar 100 ms ein.


    Zum Thema: Eine Möglichkeit wäre evtl. bei der letztmöglichen Position zum Bremsen ein DO zu schalten und mit der Schaltung dann zu prüfen ob gestoppt wird.


    Könnte man, nur hab ich darauf sehr bedingt Einfluss, bzw. ändert es an der generellen Problemstellung nichts. Wegen einem fine Punkt auf Stillstand bremsen und wieder beschleunigen kostet bei vmax und ungünstiger Pose schnell mal 500ms. Bei den Automobilzulieferern sind das Welten.

    Das mit dem DO verstehe ich ehrlich gesagt nicht?


    Ich möchte Bedingungen präzise "fly by" prüfen können und dann nur bei Bedarf stoppen/warten. Der Code im ersten Post ist im Prinzip das Vorgehen bei TriggCheckIO aus der Doku (dort beschrieben für den Fall dass der Robi ggf. auf ein gate warten muss) "erweitert" auf einen TriggInt um auch mit Variablen arbeiten zu können. Funktioniert ja prinzipiell, ich hatte nur gehofft dass es eine elegantere Lösung gibt.



    @Gerhard: Schaue ich mir morgen mal an, danke!




  • Das mit dem DO verstehe ich ehrlich gesagt nicht?

    Hab dein Post nicht so gründlich gelesen. Also im Endeffekt meinte ich das, was du schon umgesetzt hast, eleganter wirds wohl nicht mehr werden, schätze ich. Du kannst probieren den Code sauber zu halten, indem du die Traps nach der Bewegungsreihenfolge anordnest, wahrscheinlich hast du das aber auch schon gemacht. Super wäre es, wenn man in der Trap die nächst folgenden Bewegungsbefehle als Parameter hätte, dann könnte man eine allgemeine Trap schreiben, die abhängig der übergebenen Paramer schaltet.

  • Hallo Karsten


    Die Krux liegt halt im MotionPlanner:

    einerseits wollen wir das die Bewegung möglichst flüssig läuft, das bedingt den Vorlaufzeiger Bahnplanner ect.

    anderseits soll er aber gefälligts warten wenn irgendetwas in letzter Millisekunde noch nicht IO ist.


    vlt. sollten wir mal noch mit der Prefetch Time ein wenig rumspielen

  • AD