Roboter nur so schnell wie nötig fahren.... nur mal so eine Idee

Bin zwar aus der Kuka-Sparte aber finde die Idee grundsätzlich gut, bin eh ein Freund davon eher einen "vernünftigen" Dauerlauf zu haben als eine bis ans Ende ausgereizte Taktzeit mit dafür häufig verbundenen Fehlern.

Ein weiterer Vorteil wäre nach außen hin natürlich aus der der Roboter "keine Stillstands Zeiten" mehr hat, was ja alle immer gerne sehen wollen.

Sehe nur auf Dauer ein Problem von eventuell anderen abhängigen Anlagenteilen...seien es Sensoren die wegen gewissen Bauteilen früher/später kommen oder Mechaniken die verschleißen und mal länger brauchen können.

Dann fängst du nach einem "langsamen" Prozess an nach unten zu regeln, wobei der nächste aber wieder so schnell ist das die Anlage sogar auf den Roboter wartet

Vielleicht wäre es ja eher eine Idee mal z.B. 100 oder 1000 Durchgänge zu beobachten und dann gewisse Geschwindigkeiten & Beschleunigungen einfach Dauerhaft zu reduzieren wenn immer die nahezu selbe Stillstands Zeit besteht

Auf Anhieb fällt mir da keine Anlage ein, die ich kenne und bei der das Verfahren sinnig wäre.

Im Normalfall hat man mindestens einen Teilprozess der maximal schnell ausgeführt werden muss, wenn man den langsamer macht, dann geht das direkt in die Taktzeit mit ein. Was soll dann da eine pauschale Override Reduktion über den ganzen Takt?

Sinniger scheint es beim ABB, die Rampe der Beschleunigung zu reduzieren, also die zweite Zahl der accdata. Das schont dann die Getriebe und nimmt Vibrationen raus (ist ein Punkt bei Anlagen auf Grundrahmen, besonders bei MultiMove-Systemen oder wenn Bearbeitungsmaschinen drin sind)

Wobei man das nicht ohne Weiteres automatisieren kann, denn wenn dann einer den Override runtersetzt regelt sich das dann wieder rauf...

Man könnte auch die Geschwindigkeitsangabe der bewegungsunstruktionen als Variable umsetzen. Wenn man nun mit Tonern arbeitet und stillstandszeiten berechnet werden könnte man die Werte in den Variablen reduzieren.

Hatte mal sowas auf nen ABB umgesetzt.

die Zeiten die er auf Signale wartet wie Permission um in Bereiche zu fahren. Wenn an gewisse stellen zu langsam war hat er bissel erhöht wenn er dann zu schnell war wieder bissel verlangsamt. direkt in den Geschwindigkeiten der Bewegungen. nach einer Einlernphase wurden die Korrekturen verringert (bzw. wenn sie wiederholt auftraten erst korrigiert).

Resultat war schick hat sich wirklich schön eingependelt. das Roboterprogrammiererherz schlug schneller.

Dann kamen die Treiber.....

Warum fährt der so langsam..... der fährt so schnell wie er muss.... mach den schneller

aber das macht doch keinen Sinn.. geht nur auf die Mechanik.... so läufst viel schneller und flüssiger...

also sollte es raus und jetzt läuft er wieder so schnell wie es geht bis er dann steht weil der Prozess halt nicht passt.

Multitasking war da und hat ich verwendet

Kann ich nur empfehlen !

...also ich hab das schon öfters so gehandhabt. Und bei Taktzeiterhöhungen im Nachgang mich gefreut, wenn die Reserven einfach da waren.

*ggg*