question

ksugai avatar image
0 Likes"
ksugai asked Julie Weller commented

Operator's state is "travel loaded" even though he has nothing

Handing over an item.fsmimage.png


In this model, Operator1 hands over an item to Operator2 at the origin. After Operator1 finishes his task sequence, his state should be "idle" or "travel empty". However, it is "travel loaded" except for the first delivery.

This problem seems to be solved by putting 0 second delays of Task Sequence before "Finish TS of Operator1", but I want to know why 0 second delays is needed in this case.

FlexSim 23.0.8
statesynchronizetasksequence delay
image.png (174.1 KiB)
handing-over-an-item.fsm (43.3 KiB)
· 1
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

Julie Weller avatar image Julie Weller commented ·

Hi @ksugai, was Arun Kr's answer helpful? If so, please click the "Accept" button at the bottom of their answer. Or if you still have questions, add a comment and we'll continue the conversation.

If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always comment back to reopen your question.

0 Likes 0 ·

1 Answer

Arun Kr avatar image
1 Like"
Arun Kr answered ksugai commented

The "Breathe" activity solves the issue because adding a "Breathe" activity synchronizes the events. Before the loading of the item from operator1 is fully completed you are sending the operator1 token to finish the task sequence. As a result, operator1 remains in the "travel loaded" state, to avoid this issue you can add the "breathe" activity which will allow the operator1 token to remain in the "breathe" activity when the loading is completed. And finally, the state is rightly shown. Pls, refer the article on the trouble shotting process flows link given below.

https://docs.flexsim.com/en/23.1/ModelLogic/AdditionalConcepts/TroubleshootingProcessFlows/TroubleshootingProcessFlows.html#delays

Regards,

Arun KR

· 2
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

ksugai avatar image ksugai commented ·

Thank you for your reply.

I understood the reason operator 1 remains in the "travel loaded" state without "breathe" activity.

I used the 0 Second Delays of task sequence in the model, but when I replaced the activity with the general Delay activity, the state of operator1 was not rightly shown.

Please tell me why specifically the 0 Second Delays of task sequence is need in this situation.


0 Likes 0 ·
Felix Möhlmann avatar image Felix Möhlmann ksugai commented ·

The timing here is quite complex since it also depends on which operator arrives at the passover point first. You can see this when you change the position of the queues. If Operator2 arrives first, the delay task will also not work.

Another thing is that the task activities can be throught of as two steps, creating the task and executing the task.

Here is what I believe the ordering to be:

Delay Task - Operator1 arrives first:
Delay Task is generated -> Load Task is generated -> Delay Task starts -> Load starts -> Delay Task Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while item is still held by Operator1

Delay Task - Operator2 arrives first:
Load Task is generated -> Delay Task is generated -> Load starts -> Delay Task starts -> Load Task Ends -> Delay Task Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while no item is still held by Operator1

General Delay - Operator1 arrives first:
Delay Starts -> Load Task is generated -> Delay Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while item is still held by Operator1

General Delay - Operator2 arrives first:
Load Task is generated -> Delay Starts -> Load starts -> Delay Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while item is still held by Operator1

Compare this to using a Move Object activity in place of the Load activity:

Delay Starts -> Items are moved in an instand -> Delay Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while no item is still held by Operator1

You can see all this for yourself by stopping the model and stepping through it one event at a time. You will see difference of which token advances first.

In summary: Sometimes activities/tasks actually consist of multiple actions that each take 0s. A 0s Breathe will only delay the token until all other currently pending events at that time have finished. If a new event is created after the delay starts, the delay will finish first.

In those instances I personally then often use delays with a finite time (like 0.0001s) (calling them 'Long Breathe' to be able to see the resulting timing at a glance).

0 Likes 0 ·