question

Patrick Zweekhorst avatar image
0 Likes"
Patrick Zweekhorst asked Patrick Zweekhorst commented

Travel problems

Hi,

We have a model where we see some unexpected things with travel operations.
We have made a simple test model to show this: deceleration.fsm

The operator gets a travel task to queue1 and directly after this a travel task to queue2.
There are two situations (yellow operator and red operator)
Yellow:
The operator slowly accelerates to queue1, but does not reach its max speed. The next travel task however starts with its max speed. I did not expect this. I expected that the operator needed to accelerate (from 0). Why is this not the case? On further notice we noticed that the operator does not decelerate at all, also when arriving at queue2. Why does the deceleration not effect the operator?

Red:
We used custom travel tasks for this case. We hoped using end speed 0 would solve the problem, but this is not the case. Using end speed -1 does influence the result. Using -1 lets the operator decelerate correctly, why not with end speed 0? It more or less looks like end speed 0 means max speed, is that correct?

Thanks for your time,

Patrick

FlexSim 18.2.3
task executeraccelerationdeceleration
deceleration.fsm (34.6 KiB)
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Answer

anthony.johnson avatar image
0 Likes"
anthony.johnson answered Patrick Zweekhorst commented

From the user manual Task Sequence Quick Reference for the travel task:

"var1- This specifies the desired end speed for the travel operation. If 0, then the desired end speed will be the maximum speed of the task executer. A positive value will use that value directly as the end speed. If the end speed is negative, then the functionality is dependent on the navigator's logic. The standard navigators, i.e. the default navigator and the network navigator will interpret negative end speeds as an end speed of 0."

The main reason why we made the default 0 mean max speed is because quite often travel tasks will be immediately followed by load/unload tasks, which include offset travel, and we did not want operators to decel to 0 just to start up again on the offset travel. There is some argument to be made that if the operator can't reach his max speed, he should continue on the next task from his previously attained speed. Perhaps we haven't done that yet for backwards compatibility reasons.

· 1
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Patrick Zweekhorst avatar image Patrick Zweekhorst commented ·

Hi @anthony.johnson ,

That makes sense, when using the offset travel this indeed will be what you want. We will use the custom task activity in process flow to decelerate at points where we need deceleration.

Thank you for the answer

0 Likes 0 ·