Programmzeiger

Hallo robiman,

mir ist jetzt keine Möglichkeit bekannt. Der voreilende Programmzeiger wird ja auch gerade deswegen benötigt damit der Achscomputer die Bewegungen überschleifen kann. Wenn der Programmzeiger nicht voreilt muss die Bewegung angehalten werden und im nächsten Schritt kann der Achscomputer erst wieder die nächste Zielposition aus dem Programm lesen und die Bewegung berechnen und starten.

Warum möchtest du so etwas machen? Kannst du in deinem Programm nicht z. B. MoveJDO od. Trigger-Befehlen arbeiten?

Gruß
Thilbi

Eine leidige Frage, über die ich mir auch schon manchmal den Kopf zerbrochen habe. Es geht oft darum, eine Bedingung "näher" an der Bewegung abzufragen, weil sie sonst zu früh ausgewertet wird, ohne aber \Inpos zu benutzen.

Grüße,
Michael

Es gibt nach wie vor keine Möglichkeit einen Vorlaufstop ohne Bewegungsstop zu realisieren. Bei keinem mir bekannten Roboterfabrikat.
Um aber Aktionen oder Abfragen an einem bestimmten Punkt durchzuführen ohne anzuhalten bietet sich der Trigger an

Gruß
Stromer

Zitat von stromer

Es gibt nach wie vor keine Möglichkeit einen Vorlaufstop ohne Bewegungsstop zu realisieren. Bei keinem mir bekannten Roboterfabrikat.

Einen technischen Grund dafür sehe ich eigentlich nicht. Eine unserer C++ Bibliotheken, mit denen wir Roboter über deren Echtzeitschnittstellen von extern bewegen, kann das im Prinzip. Ich glaube aber auch, dass das bei "echten" Roboterprogrammen geht, die Motion Ids von Val3 sind wohl genau dafür gedacht, den Abarbeitungsstatus eines Bewegungsbefehls abzufragen.

Hallo,

ich habe mal auf der Bahn einen Trigger mit simuliertem DO gesetzt. Über das SimBoard eine Crossconnection wieder
auf einen Eingang und diesen mit waitdi in der Zukunft nur für den Programmzeiger abgefragt.

Martin

Nabend,
bei den ABB´s ist der Vorlaufzeiger immer eine Position vor dem Robi. In der Mitte vom Überschleifen wird die Logik abgearbeitet. Ich denke viel näher kannst du über ein "normales" Rapid Programm eine Bedingung nicht an den Robi schieben. Langt das nicht?
Nur über Zusatzargumente bei den Bewegungen kannst du den Vorlaufzeiger noch erhöhen. Aber das will man ja meistens überhaupt nicht.
Gruß Paulaner

Guten Morgen,

"langt das nicht". Wenn es denn so wäre mit der rel. zeitnahen Abarbeitung.
Der Programmzeiger ist teilweise so weit in der Zukunft, das er den IRB im ungünstigen
Fall einholt oder das ein WaitDI viel zu zeitig abgefragt wird und der Programmzeiger weiter geht.
Kollisionen vorprogrammiert.
Ausgänge werden ebenfalls irgendwo geschalten, wenn man keine Trigger setzt.

Martin

An Paulaner:
Wird z.B. ein Ausgang zwischen 2 MoveL gesetzt und die erste MoveL hat eine Zone von 50 so wird der Ausgang 1.5xZonengrösse oder min. 0.5s vor Erreichen der nahsten Position zur geteachten gesetzt. Also weit vorher.

Zum Problem:
Schau dir mal in der Dokumentation die Instruktion TriggIO an. Da kannst du ganz genau definieren wo du einen Ausgang setzen willst.

Hallo Leute,

ich weiß nicht, ob die Frage hier genau reinpasst, wollte aber jetzt nicht neues Thema draus machen. Ich wollte wissen, um wie viel Bewegungszeilen eilt der Vorlaufzeiger bei ABB dem Hauptzeiger voraus und kann man diesen reduzieren oder erhöhen wie bei KUKA? Danke

Zitat von spec

ich weiß nicht, ob die Frage hier genau reinpasst, wollte aber jetzt nicht neues Thema draus machen..

Warum denn kein neues Thema, wenn man sich eh unsicher ist, ob es hier reinpasst???? Versteh ich nicht.

Vorlaufzeiger beim Abb ist so ein kleines Rätsel, kenne da keine verlässlichen Angaben, einstellen lässt sich da m. W. nichts.

Hallo Spec,

es gibt immer noch keinen $Advance bei ABB.

Und eine allgemein gültige Aussage wie viele Bewegungsinstruktionen der PZ voraus eilt gibt es auch nicht. Hängt ein bisschen davon ab wie dicht die Punkte gesetzt sind und das verhält sich auch nicht unbedingt gleich wenn du z.B. mit Override fährst.

Wenn Du irgendweine Aktion an einer bestimmten Stelle brauchst wirst Du den Trigger benutzen müssen.

Hallo,

Zitat von MartinK

ich habe mal auf der Bahn einen Trigger mit simuliertem DO gesetzt. Über das SimBoard eine Crossconnection wieder
auf einen Eingang und diesen mit waitdi in der Zukunft nur für den Programmzeiger abgefragt.

Martin

die Crossconnection auf einen digitalen Eingang ist nicht notwendig, da man mit der Instruktion "WaitDO" den zuvor gesetzten Ausgang direkt abfragen kann.