Programmaufbau XTS-System Taktzeitkritisch

[Stirni]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

wir setzen für eine zukünftige Anlage ein XTS-System ein. Wir müssen je Sekunde ein Teil fertigen, wobei auf jedem Mover ein Teil liegt.
Das bedeutet, dass jede Bearbeitungsstation weniger als 1 Sekunde Zeit hat das Teil zu bearbeiten, da die Moverwechselzeit ja auch mit in die Taktzeit einspielt.
Mir geht es jetzt darum, wie viele Mover ich im System einsetzen muss, bzw. ob mehr Mover die Taktzeit verbessern und wie ich das ganze grundsätzlich programmieren sollte.

Rahmenbedingen:

• XTS-System ist als Ring aufgebaut
• Zeichnung auch nicht maßstabsgetreu
• 0,7s Zeit für die Bearbeitungsstationen, 0,3s für Moverwechselzeit (WT-Wechsel)
• 6 Bearbeitungsstationen
• 9 Mover (Werkstückträger)
• Alle Mover bewegen sich unabhängig voneinander

Zeichnung ist nur schematisch. Es gibt noch viele weitere Bearbeitungsstationen, aber das Prinzip wird denke ich so klar


Szenario 1:
Meine Überlegung war folgende:
Zu Beginn steht folgendes Szenario (Grundstellung)

Bild1: Mover in Grundstellung

Alle Mover sind leer und reihen sich hintereinander an. An der Bearbeitungsstation 1 fängt alles an, dort werden die Teile beladen, an Bearbeitungsstation 6 werden die Teile entladen.
Warum? Wenn die Anlage läuft, dann sollten sich die Mover im Idealfall so einpendeln:


Bild2: Maschine läuft, Idealauslastung

Es gibt für jede Bearbeitungsstation einen Mover, dazu zusätzlich 3 Mover für lange Wege zwischen den Bearbeitungsstationen.
Dadurch erhoffe ich mir, dass die 0,3s WT-Wechsel eingehalten werden können.
Ich frage mich allerdings, ob der Idealfall so funktionieren kann bzw. so eintreten wird, denn die Mover werden sich ja immer da der Stelle stauen,
an der die langsamste Bearbeitungsstation ist. Zu Beginn wenn die ersten 5 Teile beladen wurden sollte es so aussehen:

Bild3: Anfahren der Maschine

Jetzt ist meine Befürchtung, dass die Stelle zwischen der Station 4-5 und Station 5-6 nie mit einem „Wartemover“ befüllt wird und mir somit wieder Taktzeit verloren geht.
Ist meine Befürchtung unbegründet, weil in diesem Fall ja dann die Station 5 am langsamsten ist und somit der Mover-Stau sich vor 5 bilden wird und deshalb dieser Warte-Mover automatisch kommt?


Szenario 2:

Außerdem habe ich mir überlegt, falls Szenario 1 nicht funktioniert, wie es noch funktionieren könnte.
Dabei würde der im Bild 2 dargestellte Idealfall meine Grundstellung sein. Soll heißen, dass alle Mover leer sind und ich die Mover so positioniere wie im Bild 2 zu sehen.
Wenn die Anlage jetzt eingeschalten wird, würde nur die Bearbeitungsstation 1 den Prozess beginnen (Teil wird beladen), alle anderen würden die Mover nicht bearbeiten und weiterschicken.

Um das zu verhindern (weil dann Szenario 1 eintreten würde), würde ich alle Mover erst wieder fahren lassen, wenn alle Bearbeitungsstationen fertig sind, also auch die Bearbeitungsstation 1. Die Maschine würde dann sozusagen getaktet arbeiten.

Dadurch würde meiner Meinung nach die Idealstellung immer beibehalten. Nachteil ist, dass ich den Vorteil der Mover (diese einzeln zu verfahren) zunichte mache. Dadurch habe ich wieder weniger Flexibilität.


Das war es im Prinzip. Mache ich mir zu viele Gedanken? Bzw. wie würdet ihr vorgehen?
Ich freue mich über jede Anregung und danke schonmal für die Hilfe.

-Stirni

 

[Max2.0]

Ich persönlich habe jetzt noch keine Erfahrungen mit dem XTS von Beckhoff.
Beim SuperTrak von B&R gibt es aber eine recht gute Simulation, mit der man die Shuttleanzahl dann recht gut herausfinden kann.
Ich vermute, dass Beckhoff soetwas in der art auch anbietet.

 

[samus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir hatten eine ähnliche Anlage. Allerdings mit noch ein bisschen weniger taktzeit. Die schlussendliche Lösung war, eine Anzahl Pufferplätze vor den Stationen zu schaffen. Z.B. Station 2 hat den Mover erst losgeschickt, wenn genügend leere Pufferplätze bei der Station 3 vorhanden waren. Im idealen Zustand (der selten erreicht wurde) stand so immer ein Mover als Puffer vor der Station, bei Taktzeitverletzungen konnten noch weitere aufkolloniert werden. Diese konnten später wieder abgearbeitet werden. Für ein Abarbeiten müssen genügend Taktzeitreserven vorhanden sein.

Dies war für uns die beste Lösung. Es ist eigentlich eine Kombinatoin aus deinen beiden Szenarien.

0,3 s verfahrzeit ist aber nicht sehr einfach zu erreichen. Du musst hierzu auch spezielle Einstellungen im XTS vornehmen. Dies ist hier beschrieben: 8.1.2 Gap Ctrl Mode in diesem Mode kannst du dann aber nicht rückwarts fahren. Es ist allerdings möglich dies zur Laufzeit umzuschalten. Wir haben die Rückwärtsfahrt für eine Grundstellungsfahrt benötigt.

Viel Glück bei der Anlage! Bei weiteren Fragen kannst du dich gerne wieder melden!

 

[Stirni]

Ich persönlich habe jetzt noch keine Erfahrungen mit dem XTS von Beckhoff.
Beim SuperTrak von B&R gibt es aber eine recht gute Simulation, mit der man die Shuttleanzahl dann recht gut herausfinden kann.
Ich vermute, dass Beckhoff soetwas in der art auch anbietet.

Danke wir sind schon auf Beckhoff zugegangen. Diese haben die "Reserve"-Mover auch empfohlen. Jedoch hilft mir das leider erstmal nicht mit meiner Strategie weiter. Trotzdem danke für die Meldung.

-Stirni

 

[Stirni]

Wir hatten eine ähnliche Anlage. Allerdings mit noch ein bisschen weniger taktzeit. Die schlussendliche Lösung war, eine Anzahl Pufferplätze vor den Stationen zu schaffen. Z.B. Station 2 hat den Mover erst losgeschickt, wenn genügend leere Pufferplätze bei der Station 3 vorhanden waren. Im idealen Zustand (der selten erreicht wurde) stand so immer ein Mover als Puffer vor der Station, bei Taktzeitverletzungen konnten noch weitere aufkolloniert werden. Diese konnten später wieder abgearbeitet werden. Für ein Abarbeiten müssen genügend Taktzeitreserven vorhanden sein.

Dies war für uns die beste Lösung. Es ist eigentlich eine Kombinatoin aus deinen beiden Szenarien.

0,3 s verfahrzeit ist aber nicht sehr einfach zu erreichen. Du musst hierzu auch spezielle Einstellungen im XTS vornehmen. Dies ist hier beschrieben: 8.1.2 Gap Ctrl Mode in diesem Mode kannst du dann aber nicht rückwarts fahren. Es ist allerdings möglich dies zur Laufzeit umzuschalten. Wir haben die Rückwärtsfahrt für eine Grundstellungsfahrt benötigt.

Viel Glück bei der Anlage! Bei weiteren Fragen kannst du dich gerne wieder melden!

@samus das klingt sehr spannend. Das mit dem GapControlMode war mir bewusst, da ich schon mehrere XTS-Systeme programmiert habe, jedoch nicht so taktzeitkritisch.
Wir lösen es so, dass während der Grundstellungsfahrt alle Mover in eine andere CA-Gruppe umgruppiert werden. Diese CA-Gruppe hat den GapControlMode "mcGapCtrlModeStandard" und die Gapregelung auf "mcGapCtrlDirectionBoth", somit wird das Gap auf beiden Seiten ausgeregelt, ist aber langsamer (ist aber egal, da eh nur Grundstellungsfahrt). Wenn die Anlage fertig ist mit der Grundstellung, gruppiere ich alle Mover in eine andere CA-Gruppe um, welche dann auf "mcGapCtrlModeFast" und "mcGapCtrlDirectionPositive" umstellt.
Die 0,3s Moverwechselzeit wird nämlich nur so erreicht, da gebe ich dir Recht.


Mich würde noch interessieren, wir ihr die Mover aufkolloniert habt? Es muss doch dann sichergestellt werden, dass die Bearbeitsstation davor auf jeden Fall schneller ist als die nächste Bearbeitungsstation?

Danke und Grüße

-Stirni

 

[winnman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich gebe zu, ich gar keine Ahnung von solchen Prozessen.
Hab aber mal folgendes überlegt:

die langsamste Station muss ja den Takt für alle vorgeben.

Also die Beschickung an Station1 so takten, das vor der langsamsten Station etwas Reserve steht, aber noch platz für 1 - 2 zusätzliche mover bleibt.

Dann kann man ja über den Bestückungstakt das ganze steuern.

 

[samus]

Bei uns blieben sie in der selben Gruppe. Über die XTS Utilities kann man dies umschalten. Ich weiss aber nicht mehr genau wie. Bei Bedarf könnte ich dies auch nachschauen im Program.

Grundsätzlich werden sich die Mover irgendwo stauen. Es werden nie alle Station gleich schnell sein. Über die Anzahl Pufferplätze kann man aber kontrollieren, dass nicht alle Mover auf die selbe Station wollen, sondern schon bei Stationen vorher angehalten werden.





Wir haben es schlussendlich bei der letzten Methode belassen, allerdings könnte man es auch noch deutlich intelligenter machen:
Ich habe dies aber nie getestet!
Jede Station wartet "scheinbar starr" bis die Taktzeit fertig ist. Dies geschieht auch, wenn die Station schneller ist. Ist der Puffer der Station voll, so werden die Mover direkt nach der Bearbeitungszeit weggeschickt. So kann die Station aufholen, ohne einen HickUp zu provozieren. So kann man auch noch zusätzliche Mover einsetzen, hätte immer einen genügend grossen Puffer welcher sich in Ausnahmesituationen auch auf und wieder abbauen kann.

Gruss Samus

 

[hoge84]

Es wäre interessant wieviel Gewicht wird mit dem mover befördert . Dann kann man überhaupt sagen ob die 0.3s möglich sind.

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich habe mit so schnellen taktraten ehr wenig zu tun.
aber meine gedanken.
die langsamste station (z.b. st5) gibt den takt vor.
egal welche. es wird sich also vor dieser station stauen.
und wenn jetzt an irgendeiner anderen station wt fehlen ist das doch noch nicht tragisch solange
vor der langsamsten station noch zu bearbeitende wt liegen
die transportzeit kann ich hier vernachlässigen da ja vor der langsamsten station ein stau ist.

oder hab ich hier einen denkfehler?

 

[samus]

oder hab ich hier einen denkfehler?

Das stimmt schon, aber wenn man ein XTS einsetzt, möchte man meistens auch von der Fexibilität profitieren. In deinem Fall würde sich eine Taktzeitverletzung der längsämsten Station direkt auf die Maschinentaktzeit auswirken. Wenn alle Stationen Puffer haben, so könnten diese Stationen aufholen und so den Taktzeitverlust wieder gutmachen.

Bei einem einfachen Prozess zahlt sich wahrscheinlich der Aufwand nicht aus, diese Funktionalität zu implementieren, in diesem Falle nutzt man das XTS dann halt wie ein starres System.

 

[Blockmove]

oder hab ich hier einen denkfehler?

Das interessante ist nicht der Stau, sondern das Auflösen des Staus und die unterschiedlich langen Wege zwischen den Stationen.
Natürlich spielt die Moveranzahl auch noch ne Rolle.
Frag bei dem Thema 5 Leute und du kriegst 10 Lösungsansätze.
Mein erster Ansatz wäre ein virtueller Rundtakttisch.
In den langen Transportstrecken zusätzliche Leerstation einfügen.
Damit bekommst du recht konstante Verhältnisse und brauchst die wenigsten Mover.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schaffen es denn die WTs schnell genug von Station x bis zum Stauende der Station x+1, auch wenn der Puffer mal leer ist? Die Taktzeit von einer Sekunde muss ja grundsätzlich unterboten werden, damit sich ein ggf. leerer Puffer wieder füllt.

.. Ok klar, es werden ja dann auch mehrere auf die Reise geschickt.

 

[Stirni]

Ich gebe zu, ich gar keine Ahnung von solchen Prozessen.
Hab aber mal folgendes überlegt:

die langsamste Station muss ja den Takt für alle vorgeben.

Also die Beschickung an Station1 so takten, das vor der langsamsten Station etwas Reserve steht, aber noch platz für 1 - 2 zusätzliche mover bleibt.

Dann kann man ja über den Bestückungstakt das ganze steuern.

Das wird nicht funktionieren, da wenn Station1 am langsamsten ist trotzdem ein Engpass an Station 5 sein wird, da hier die Wegstrecke auch mit betrachtet werden muss. (angenommen, Station 5 ist 0,1s schneller als Station 1 aber durch die längere Wegstrecke beträgt die Mover-Wechselzeit nicht 0,3s sondern 0,6s dann wäre Station 5 wieder am langsamsten.

Bei uns blieben sie in der selben Gruppe. Über die XTS Utilities kann man dies umschalten. Ich weiss aber nicht mehr genau wie. Bei Bedarf könnte ich dies auch nachschauen im Program.

Grundsätzlich werden sich die Mover irgendwo stauen. Es werden nie alle Station gleich schnell sein. Über die Anzahl Pufferplätze kann man aber kontrollieren, dass nicht alle Mover auf die selbe Station wollen, sondern schon bei Stationen vorher angehalten werden.



Anhang anzeigen 76378

Wir haben es schlussendlich bei der letzten Methode belassen, allerdings könnte man es auch noch deutlich intelligenter machen:
Ich habe dies aber nie getestet!
Jede Station wartet "scheinbar starr" bis die Taktzeit fertig ist. Dies geschieht auch, wenn die Station schneller ist. Ist der Puffer der Station voll, so werden die Mover direkt nach der Bearbeitungszeit weggeschickt. So kann die Station aufholen, ohne einen HickUp zu provozieren. So kann man auch noch zusätzliche Mover einsetzen, hätte immer einen genügend grossen Puffer welcher sich in Ausnahmesituationen auch auf und wieder abbauen kann.

Gruss Samus

Wow vielen Dank für die ausführliche Antwort. Die Mover können mithilfe von z.B. MC_UngroupAllAxes und MC_AddAxisToGroup umgruppiert werden (wie du sagst über XTS Utility).
Der Grund warum ich Station 1-4 so gezeichnet habe ist, dass dort eine Presse stehen wird, welche 4 Mover gleichzeitig bearbeitet. Dadurch werden diese Stationen immer gleich schnell sein.
Dein Grundgedanke scheint sich dann schon eher auf Szenario 2 zu beziehen, dass die Mover starr warten. Nur wenn ein Stau vor der Station ist, werden die Mover wieder weiter geschickt.

Was ich jedoch immer noch nicht verstehe: Warum sollte eine Station überhaupt warten, bis Sie den Mover wegschickt? Wenn die Station schon früher fertig ist und kein Mover an der Warteposition angekommen ist, würde ich den Mover trotzdem weiterschicken, dann ist halt meine Wartezeit zum nächsten Mover größer, aber an der Ausbringung ändert sich doch da gar nichts oder? Ich sehe den Vorteil daran noch nicht so richtig.

Soll heißen:


Ich tendiere gerade zu eher diesem Vorgehen, in der Hoffnung, dass sich alles so einpendelt wie es soll.
Sicher bin ich mir allerdings überhaupt nicht.

Es wäre interessant wieviel Gewicht wird mit dem mover befördert . Dann kann man überhaupt sagen ob die 0.3s möglich sind.

Das wurde von Beckhoff berechnet bzw es kam die Aussage dass das möglich ist, wenn der "mcGapCtrlModeFast"-Mode genommen wird.
Ich weis jetzt nicht genau das Gewicht, ist aber ein Hepco-Mover mit 4 Führungsrollen und ein kleiner mechanischer Aufbau.
Ich schätze mal 1,5kg wird der WT wiegen.

Das interessante ist nicht der Stau, sondern das Auflösen des Staus und die unterschiedlich langen Wege zwischen den Stationen.
Natürlich spielt die Moveranzahl auch noch ne Rolle.
Frag bei dem Thema 5 Leute und du kriegst 10 Lösungsansätze.
Mein erster Ansatz wäre ein virtueller Rundtakttisch.
In den langen Transportstrecken zusätzliche Leerstation einfügen.
Damit bekommst du recht konstante Verhältnisse und brauchst die wenigsten Mover.

Genau das war auch mein Gedanke mit dem Idealfall im Bild2.
Aber hier genau diesselbe Frage wie bei samus:
Was ich jedoch immer noch nicht verstehe: Warum sollte eine Station überhaupt warten, bis Sie den Mover wegschickt? Wenn die Station schon früher fertig ist und kein Mover an der Warteposition angekommen ist, würde ich den Mover trotzdem weiterschicken, dann ist halte meine Wartezeit zum nächsten Mover größer, aber an der Ausbringung ändert sich doch da gar nichts oder?

Schaffen es denn die WTs schnell genug von Station x bis zum Stauende der Station x+1, auch wenn der Puffer mal leer ist? Die Taktzeit von einer Sekunde muss ja grundsätzlich unterboten werden, damit sich ein ggf. leerer Puffer wieder füllt.

.. Ok klar, es werden ja dann auch mehrere auf die Reise geschickt.

Genau das schaffen sie eben nicht, daher die zusätzlichen Mover im System. Diese sollen die langen Strecken überbrücken, da ein Stau ja immer an der langsamsten Station entsteht (also auch die Wegstrecken mit betrachtet werden müssen).

-Stirni

 

[Onkel Dagobert]

.. Der Grund warum ich Station 1-4 so gezeichnet habe ist, dass dort eine Presse stehen wird, welche 4 Mover gleichzeitig bearbeitet. Dadurch werden diese Stationen immer gleich schnell sein...

Das ist aber nett von dir, dass du diese Information nachreichst. Dann fahren die WTs im Vierer-Pulk ein und aus? Und die Bearbeitungszeit ist wahrscheinlich wesentlich länger als bei den anderen Stationen? Das ist natürlich ein gewaltiger Grund für Pufferplätze davor und danach.

 

[Stirni]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist aber nett von dir, dass du diese Information nachreichst. Dann fahren die WTs im Vierer-Pulk ein und aus? Und die Bearbeitungszeit ist wahrscheinlich wesentlich länger als bei den anderen Stationen? Das ist natürlich ein gewaltiger Grund für Pufferplätze davor und danach.

Naja es braucht nur einen Puffer-Platz davor aber auch nur weil der Weg von Bearbeitungsstation 6 zu 1 sehr groß ist, ansonsten bräuchte ich gar keinen Puffer-Platz, weil die Mover ja immer nur einen Platz weiter rutschen. Sehe jetzt nicht den gewaltigen Grund für viele Puffer-Plätze.

-Stirni

 

[Onkel Dagobert]

Ok, ich bin raus.

 

[Stirni]

Ok, ich bin raus.

Warum? Vielleich verstehe ich auch etwas falsch. Warum meinst du, dass es "viele" Puffer-Plätze braucht?

EDIT:
Nein im Vierer-Pulk fahren Sie nicht ein und aus. Es wird immer nur eins weiter gefahren. Aber ich brauche keine Puffer-Plätze innerhalb der Stationen, weil ich ja weiß, dass alle Stationen gleich schnell fertig sind, da sie durch eine einzige Presse bearbeitet werden.

Es ist nicht so, dass vier Mover "warten" und vier Mover bearbeitet werden. Es werden 4 Mover bearbeitet, aber diese werden immer nur um eine Station weiter gefahren.

-Stirni

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich sehe das auch so wie @Blockmove - du mußt zusehen, dass der Abstand zwischen den Stationen relativ gleich ist - also ein virtueller Rundschalttisch. Ich würde also auf den langen Strecken relativ viele Pufferplätze einbauen. Das würede jetzt nicht zwangsläufig heißen, dass du auch viele WT's brauchst - hilft aber wahrscheinlich.
Grundsätzlich kann eine Station, wenn fertig gearbeitet, ihren WT ja auch die Reise schicken .. wenn die nächste Station aufnahmebereit ist / wird.
Du hast jetzt ja keine Weglängen genannt, naja und du hast ja auch geschrieben, dass das nicht dein erstes System dieser Art ist - ich halte aber die 1 Sekunde für sehr sportlich, bei der aktuellen Zeichnung und einer Bearbeitungszeit von 0,7s an der langsamsten Station. So etwas würde aus meiner Sicht wirklich nur ein Rundschalttisch schaffen ...

 

[hoge84]

Wenn du mir die genaue Länge bzw. Anzahl der Xts Module sagst und wo sich die Stationen befinden dann kann ich dir eine Simulation machen. Dann kann man abschätzen wieviel mover du benötigst

 

[Onkel Dagobert]

Warum? Vielleich verstehe ich auch etwas falsch. Warum meinst du, dass es "viele" Puffer-Plätze braucht?...

Ich hatte den Begriff "gleichzeitig" anders interpetiert als du.