Zone allocation: bug or error in the implementations?

Question

question

Alessio Merlo asked Jun 29, '17 Jordan Johnson answered Jul 7, '17

Zone allocation: bug or error in the implementations?

Hi,

today I had a trouble with the zone, but I didn't understand if it is a bug or my error.

You can reproduce the issue from the model zoneallocation.fsm in this way:

- reset the model;

- click step 11 times;

At this point the token left partition 1 of the zone and allocated partition 2.

Next step it re-allocates partition 1.

The second allocation allows to know if there is a token which is waiting in the queue. In this model I exclude the logic, but I need to distinguish this case.

With another step the token leave the partition, but doesn't leave the partition 1 but 2. Why? Immediatly I search an error in the implementation, but I don't find it. Is it a bug?

Thanks for the support!

Software Version:

FlexSim 17.1.2

bug report zone partition

step1.png (67.8 KiB)

step2.png (69.1 KiB)

step3.png (73.3 KiB)

zoneallocation.fsm (21.1 KiB)

Answer 1 · 2017-07-07T21:52:33Z

Jordan Johnson answered Jul 7, '17

The issue is that the Zone records which partition a token belongs in when the token enters. It is that record, not the token's current label values, that the zone refers to when the token exits.

In your case, you enter the zone with opnum 1, so the zone creates a record for that token, saying it's in partition 1. Then you enter the zone again, and the zone creates another record, saying the token is in partition 2.

When you exit the zone, the zone destroys the oldest record for that token. At that point, the token appears to be in partition 2 (the record for partition 1 gets destroyed).

When you get to the next Enter Zone, the token's opnum label is again at 1, so the zone creates another record for that token, saying it's in partition 1. For the next exit, the zone finds the oldest record (saying the token is in partition 2) and destroys it. At this point, the token appears to be in partition 1, rather than in partition 2.

Said another way, entering a zone multiple times creates multiple records. You can only destroy those records in the order they were created.

You may instead consider using a Resource. In the Resource's Reference field, just type an array of all the possible opnums, maybe something like this: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. For the count, use the length of the array. Then, when you acquire, make sure to use a query: WHERE value == puller.opnum. Using a resource, you can acquire and release in a much more specific order.

question