Programmaufbau XTS-System Taktzeitkritisch

[samus]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

Damit du den Stau im Griff hast. Im Normalfall verhält sich das XTS dann wie ein Rundtisch, sollte aber ein Prozess manchmal länger benötigen(bei uns waren dies vorallem flexible Zuführungen) so kann das XTS diese Verzögerung wieder kompensieren. Dies geht halt nur wenn kein Stau vorhanden ist. Wenn sich zum Beispiel alle Mover bei einer Station stauen(auch wenn in Taktzeit) so hat eine Taktzeitverletzung dieser Station direkten Einfluss auf die Maschinentaktzeit. Hat es keinen Stau, so gibt es Reserven bei der nachfolgenden Station und die "langsame" Station könnte die Verzögerung in späteren Takten wieder aufholen.

Ob sich der Aufwand für die Programmierung lohnt, das musst du selber bestimmen. Wir haben dies am Schluss nicht mehr implementiert, da die Prozesse zum Schluss "genügend" stabil waren. Wenn ich allerdings ein neues XTS einsetzen müsste, so würde ich dies auf jeden Fall machen.

Im Minimum würde ich 1 Pufferplatz vor jeder Station empfehlen. Das heisst bei dir dann + 3 Mover. Hier hast du aber die oben genannte Sicherheit nicht! Wie viele genau ist schwer zu sagen, ich schätze +6 Mover. Aber wie gesagt, ist alles sehr abhängig von den Prozessen und der Maschine.

 

[Stirni]

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

Danke, das muss ich dann auf Montag verschieben ich habe die Daten jetzt nicht parat. Ich weiß, dass es 10,75m Länge hat das System und insgesamt 41 Stationen beinhaltet (mit Wartepositionen). Die Wegstrecken unterscheiden sich aber teils drastisch. Der Längste Weg zwischen den Stationen ist ca 3,5m der kürzeste 100mm

-Stirni

 

[Stirni]

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 ...

Damit du den Stau im Griff hast. Im Normalfall verhält sich das XTS dann wie ein Rundtisch, sollte aber ein Prozess manchmal länger benötigen(bei uns waren dies vorallem flexible Zuführungen) so kann das XTS diese Verzögerung wieder kompensieren. Dies geht halt nur wenn kein Stau vorhanden ist. Wenn sich zum Beispiel alle Mover bei einer Station stauen(auch wenn in Taktzeit) so hat eine Taktzeitverletzung dieser Station direkten Einfluss auf die Maschinentaktzeit. Hat es keinen Stau, so gibt es Reserven bei der nachfolgenden Station und die "langsame" Station könnte die Verzögerung in späteren Takten wieder aufholen.

Ob sich der Aufwand für die Programmierung lohnt, das musst du selber bestimmen. Wir haben dies am Schluss nicht mehr implementiert, da die Prozesse zum Schluss "genügend" stabil waren. Wenn ich allerdings ein neues XTS einsetzen müsste, so würde ich dies auf jeden Fall machen.

Im Minimum würde ich 1 Pufferplatz vor jeder Station empfehlen. Das heisst bei dir dann + 3 Mover. Hier hast du aber die oben genannte Sicherheit nicht! Wie viele genau ist schwer zu sagen, ich schätze +6 Mover. Aber wie gesagt, ist alles sehr abhängig von den Prozessen und der Maschine.

Ich denke beide Antworten gehen in dieselbe Richtung.
@Larry Laffer
"Grundsätzlich kann eine Station, wenn fertig gearbeitet, ihren WT ja auch die Reise schicken .. wenn die nächste Station aufnahmebereit ist / wird."
Ich schicke den WT immer los, auch wenn die neue Station nicht aufnahmebereit ist, weil noch ein Mover bearbeitet wird. Dadurch bildet sich ja ein Stau vor dieser Station. Genau das will ich ja aber auch, damit die Wegstrecke schonmal verkürzt wird. Wenn die Station dann fertig ist, hat der Mover ja nur noch einen ganz kurzen Weg in die Station, weil er schon parat steht.

@samus
Eine Station kann die Verzögerung doch nur kompensieren, wenn ein Stau da ist? Wenn diese Station länger braucht, ist es doch von Vorteil, dass direkt noch 2 oder 3 Mover hinten dran stehen, denn dann kann die Station möglichst schnell wieder einen Mover bearbeiten?

Vermutlich kapiere ich immer noch nicht ganz wie ihr das genau meint?
Vielen Dank schonmal und schönes Wochenende.

-Stirni

 

[samus]

Eine Station kann die Verzögerung doch nur kompensieren, wenn ein Stau da ist? Wenn diese Station länger braucht, ist es doch von Vorteil, dass direkt noch 2 oder 3 Mover hinten dran stehen, denn dann kann die Station möglichst schnell wieder einen Mover bearbeiten?

Ja natürlich.
Für mich ist ein Stau, wenn die Anlage durch eine Station gebremst wird. Alle Mover stauen sich dann an dieser Station auf und blockieren unter Umständen auch vorhergehende Stationen. Wenn dann die bremsende Station eine Taktzeitverletzung hat, dann wirkt sich dies direkt auf die ganze Maschine aus.
Die gepufferten Mover vor den Stationen sind/sollten Normalfall sein und wurden darum von mir nicht als Stau bezeichnet. (Obwohl sie sich natürlich auch stauen )

Einfach gesagt, bei einer laufenden Maschine sollten die Pufferplätze belegt sein/werden. Bei einer Stauenden Maschine warten alle Mover auf eine Station oder werden durch diese blockiert. So sehe ich den Unterschied. Ich hoffe es ist nun ein bisschen klarer. Ansonsten versuche ich mich später nochmal mit einer Grafik...

 

[Larry Laffer]

@Stirni :
Ich denke auch, dass @samus und ich in etwa dasselbe meinen.
Ich würde einen WT nicht auf die Reise schicken wenn bei der nächsten Station kein Platz mehr davor ist. Nehmen wir mal an, dass zwischen Station 4 und 5 Platz für 4 WT's wären (wenn Station 5 bereits belegt ist). In diesem Fall würde ich von Station 4 keinen WT mehr losschicken wenn diese Anzahl erreicht ist.
Umgekehrt aber solltest du, gerade wegen des langen Wegs zwischen den beiden Plätzen, immer schon vor Station 5 einen WT parat stehen haben wenn diese fertig ist. Während der Bearbeitungszeit von Station 5 kann natürlich von Station 4 durchaus schon ein neuer WT nachrücken ...

Ich hoffe, dass es jetzt etwas besser erklärt ist ...

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich wär vorsichtig mit den ganzen Puffern und würde wirklich mit der virtuellen Nachbildung eines Rundtakttisches starten. Nicht mal den Mover losschicken wenn die einzelne Station fertig ist.
Das ergibt den stabilsten Zustand. Die langsamste Station bestimmt die Ausbringung. Da ändert kein Puffer was.
Sieht natürlich anders aus, wenn ich keine stabile Prozesse in Stationen hab. Dann kann eine lose Taktung besser sein.

 

[Wondermike_2000]

Wie bekomme ich heraus das ein Mover im Stau steht?
Oder anders, ich möchte pro Mover u.a. ein Rückmeldungsbit kreieren, dass mit sagt der Mover ist moving (weil noch nicht am Ziel), steht aber momentan im Stau.
Wie erzeuge ich so ein Bit?

 

[Stirni]

Wie bekomme ich heraus das ein Mover im Stau steht?
Oder anders, ich möchte pro Mover u.a. ein Rückmeldungsbit kreieren, dass mit sagt der Mover ist moving (weil noch nicht am Ziel), steht aber momentan im Stau.
Wie erzeuge ich so ein Bit?

Über die zyklische NC-PLC Struktur:

Beckhoff Information System - English

Components for Automation and Control: TwinCAT NT-Realtime-System, Bus terminal, Industrial PC, BECKHOFF-Lightbus

infosys.beckhoff.com

Wenn "NotMoving" und nicht "InTargetPos" und "HasJob" würde ich das mal ausprobieren.

-Stirni

 

[hoge84]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vorsicht bei der Verwendung von einigen Bits in dieser Struktur. Die gelten nur wenn der mover nicht im Stau steht.

 

[Stirni]

Vorsicht bei der Verwendung von einigen Bits in dieser Struktur. Die gelten nur wenn der mover nicht im Stau steht.

Welche sind das konkret?

-Stirni

 

[hoge84]

Wenn der mover im Stau steht wird nicht über die nc gerechnet sondern wird der mover mit externen sollwert betrieben. In diesem Modus sind die Bits von der nc nicht gültig.

 

[Wondermike_200]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann man eigentlich bei mc_move_absolut die Zielkoordinate während der Fahrt noch ändern?

 

[hoge84]

Der move_absoluteCa übernimmt mit jedem Execute neue Werte.

 

[Wondermike_200]

Der move_absoluteCa übernimmt mit jedem Execute neue Werte.

Also nicht während der Fahrt, zB weil unterwegs noch Ziel Korrekturwerte von der Bildverarbeitung kommen.

 

[hoge84]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auch während der Fahrt. Das ist der große unterschied zum normalen move_absolute Baustein. Einzige Bedingung ist die mover müssen in einer kollisionsgruppe sein.
Wenn der kollisionsschutz aktiv wird nimmt er auch keine Befehle an

 

[Wondermike_2000]

Auch während der Fahrt. Das ist der große unterschied zum normalen move_absolute Baustein. Einzige Bedingung ist die mover müssen in einer kollisionsgruppe sein.
Wenn der kollisionsschutz aktiv wird nimmt er auch keine Befehle an

Also ich fahre die einzelnen Mover mit "MC_MoveAbsoluteCA" .
Sicher stehen die einzelnen Mover dabei öfter im Stau bevor sie Ihr Ziel erreichen.
Wenn ich also irgendwann bevor das Ziel erreicht wird am Bausteineingang eines Movers den Wert "Position" ändere, fährt er zum geänderten Ziel?

 

[hoge84]

Wenn du die Position änderst braucht das bExecute eine positive Flanke. Dann fährt der mover auf die neue Position egal ob er steht oder einen aktuellen fahr Befehl hat