Differences in Operator Behaviors at LoadTS timing

Differences in Operator Behaviors at LoadTS timing

loc_khieu
Contributor Contributor
153 Views
2 Replies
Message 1 of 3

Differences in Operator Behaviors at LoadTS timing

loc_khieu
Contributor
Contributor

Hello everyone — first post here, so please redirect me if this isn't the right place.

 

I'm a beginner in FlexSim, practicing along with Task Logic Tutorial 2, and I've observed some unexpected operator behavior when process times are unequal.

 

Setup:

  • EqualProcessingTime — Both Processor1A and Processor1B have a 10s process time. Operators wait at their respective processor until processing completes, then walk back to the StandardQueue for the next box. This works as expected.
  • UnequalProcessingTime — Processor2A is set to 2s and Processor2B to 30s; everything else is identical to EqualProcessingTime.

Unexpected behavior (starting ~t = 40s):

  1. Operator2A stands idle at Processor2A even though processing is complete and two boxes are waiting at StandardQueue2.
  2. Operator2B leaves Processor2B mid-process, walks to StandardQueue2, picks up a box, and delivers it to Processor2A — while Operator2A remains idle the entire time.

Can anyone explain why the operators behave differently between the two simulations? Screenshot and .fsm file attached below. Thank you!

 

loc_khieu_0-1780680154229.png

 

0 Likes
Accepted solutions (1)
154 Views
2 Replies
Replies (2)
Message 2 of 3

FelixMoehlmann
Collaborator
Collaborator
Accepted solution

The Operators are released after they unload the item to the processor. There is no logic forcing them to stay at the processor until the process finishes.

When a resource is linked to a group it internally uses a list to manage the objects. Initially the order of operators on that list would be the same as their ordering in the respective group. Without a query that might influence which objects gets acquired, the token will be assigned the first/highest entry on the list. When the resource gets released the operators gets added to the bottom of the list. So if both operators are available, the token will acquired the operator that has been idle for longest.

With the equal processing times in the first case, this "round robin" logic results in each operator only feeding one of the processors. In the second case, the first processor can finish two items in the time it takes the other one to finish one item. So which operator feeds what processor frequently changes.

0 Likes
Message 3 of 3

loc_khieu
Contributor
Contributor

@FelixMoehlmann Thank you for the explanation. Following your line of reasoning, I could see that, for unequal-process-time case, I could force Operator2B to stay with Processor2B till process completion by repositioning the "Release Operator" as shown below. 

loc_khieu_0-1780918302133.png

 

A follow-up question: are there property attributes of Operator that I can adjust to have them walking back and waiting at the Queue after being released, instead of waiting at the Processor? One method I know of is using a Travel activity. Thank you. 

0 Likes