Hi all,
I am currently struggling to understand why my model is generating a different amount of items between runs. It varies between 80 and 82 items. Furthermore, it generates a different amount of items when I change logic downstream in the model. I do not think this should happen.
I have attached the model. Boxes are generated by Source3 in the 3D environment as seen in the image below. Whenever a box is created, the event triggered source "Source 3 Creation" creates a token in processflow. I then assign labels to each token to keep track of the order in which I will create boxes and the processors they have to go to. I then create the boxes in the "Arrival" queue and change the visual of the box.
The box then goes through the first check. Queue5 in front of Check1 can only have 1 box in it at a time. I use a subflow on "Use Transport" to check the contents of Queue5 and make the box wait at Check1 if Queue5 is occupied as shown in the image below. If Queue5 is not occupied, I move the object into Queue5.
The boxes then go through Check2 and queue in Queue1 before going to the third check. Queue1 has a maximum capacity of 2.
Check3In and Check3Out share the same operator. I used the same subflow on "Use Transport" for both Check3In and Check3Out as shown below to achieve this. When a box in Check3In requires transport, the "ShareCheck" subflow starts at the "StartIn" activity. When a box in Check3Out requires transport, the "ShareCheck" subflow starts at the "StartOut" activity. Both activity blocks starting with "StartIn" and "StartOut" aqcuire the same resource linked to one operator in Group1.
After the third check boxes are sent to be processed by either Processor4, Processor3 or Processor5 depending on the Processor label I assigned in the beginning. All the processors must share the same operator. I used a dispatcher so I can later change the amount of operators.
After Check3Out is done, the LastCheck is done. I again use a subflow (as with Queue5) to ensure that only 2 boxes are in Queue9 at a time as shown below.
Lastly, 75% of the boxes have to be delayed in Queue9 while 25% to not have to be delayed further in Queue9. Furthermore, boxes have to leave in the order they came into Queue9. Thus if a box comes into Queue9 that does not have to be delayed, it has to wait for any box that came in before it to finish its delay before it can leave. To do this, I used an Event-triggered source (Box enter Queue 9) that creates tokens as boxes come into Queue9. All the tokens are pushed to a list with a max wait timer of 0 seconds. The entries are kept on early release. The tokens are then either delayed or not depending on a 75%, 25% split enforced by a decision activity. Lastly, before the tokens leave, they are pushed to another list (List2) before the box is destroyed.
I create s single token with the Keep box order schedule source in processflow that pulls from the first list to get the box number and pulls from List2 then later on according to box number. This ensures the boxes leave in the correct order.
I saw that if I unconstrain the content of Queue9 (if I take out the wait for event activity in my "Queue9 Capacity" subflow), Source3 creates a different amount of items for the same amount of runtime.
I also saw that if I should take out the logic that ensures boxes leave in the same order they come in at Queue9, Source3 generates a different amount of items for the same amount of runtime.
I do not think this should happen. Source 3 should generate the same amount of items for the same amount of runtime regardless of how I change the logic in the last step. I agree that more or less boxes should go through the system, but the amount that is generated in the beginning should stay the same.
Thank you for your help
