Apparent error in model for Conveyor Tutorial 1.3 part 4

Question

question

Claire Krupp asked Dec 3, '19 Claire Krupp commented Dec 13, '19

Apparent error in model for Conveyor Tutorial 1.3 part 4

I am working through the conveyor tutorials using version 19.2.4.

Everything is working fine up to 1.3 part 3. The slugs are pushed through using the Merge Controller by "Round Robin if available". If a new box arrives on the Slug conveyor as the slug starts to move, it does not get released with the slug, but has to stop and is not released until the following slug.

Then I added the logic to make the boxes variable sizes. It appears to work fine, but then at time 125 things get a little weird! A slug of red boxes starts to enter the merging conveyor. At the same time a new box arrives at the beginning of the red conveyor. The slug goes through and is nearly past the yellow slug, which will be released next, but then the new red box follows the slug and enters the merging conveyor. When it gets close to the yellow slug, the yellow slug is released and they crash into eachother!

This happens multiple times as I let the model run, but only to the red boxes. All the others behave as expected. I haven't used the Merge Controller before so I have no idea if it is something I have done wrong, or if this is a bug!

(btw while debugging I also noticed that when you add random sizes to the source, the pattern of arrivals types changes, which should not be happening if your random number streams are independent!)

Model attached. I can also give you the model for 1.3 part 3 if you need it.

conveyor tutorial merge controller

conveyor-tutorial-1-3d-with-error.fsm (48.0 KiB)

· 2

5 |100000

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

Claire Krupp commented · Dec 04, 2019 at 01:32 PM

Update: it does happen to the other colors if you let it run long enough. Seems to be related to times when no other line has a slug ready to go.

0 ·

Claire Krupp commented · Dec 09, 2019 at 04:06 PM

@Joshua S it appears that no-one is looking at this. I am worried that the Merge Controller is not working properly in this version and I will not be able use that functionality in my model.

0 ·

Answer 1 · 2019-12-10T18:31:40Z

Braydn T answered Dec 10, '19 Claire Krupp commented Dec 13, '19

@Claire Krupp

With Merge controllers you often have to tweak things. I moved point 4 down the conveyor and it worked fine. You are right about pattern arrival types, I will see what I can find out about that.

Here is an example: conveyor-tutorial.fsm

conveyor-tutorial.fsm (48.0 KiB)

· 7

5 |100000

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

Claire Krupp commented · Dec 11, 2019 at 04:22 PM

I'm afraid the problem is still there @Braydn T.

Run it to time 500 then watch. At 506.298 there is a traversal event for the "Slug1" conveyor. The box should stop, but it keeps going...and then a second box....

1 ·

merge-problem.png (47.6 KiB)

Braydn T Claire Krupp commented · Dec 12, 2019 at 05:31 PM

I moved point4 farther down the conveyor, and the collision at 506 went away again. This is very common behavior with Merge controllers, and typically you just need to wiggle them to get the to work perfectly. Decision Point 4 is the "release the lane" controller. The farther down the lane it is, the more space FlexSim will calculate it needs between slugs being released. If you need more space, move it farther down.

1 ·

Claire Krupp Braydn T commented · Dec 13, 2019 at 08:35 PM

But what about the fact that it is releasing single boxes and not waiting for a slug to build up? I think that is what is causing the problem. The spacing seems to be fine when a slug is released properly.

And when the single boxes are released it seems that they are invisible to the other boxes. There must be a parameter/variable that is not set correctly.

1 ·

Braydn T commented · Dec 10, 2019 at 07:13 PM

I talked to the developers and the reason why the pattern of colors is different is the distribution that chooses the color and the distribution that chooses the shape are using the same random stream. Before you had the on entry trigger that changed the shape, the duniform stream would grab the first number in the list, assign it to the first object and chooses a type label based on it and change the color to match. Now, when you have it changing to a random shape as well, it does what it did before, but it takes the next random number in the stream and uses that to assign the shape. So before, you were using 1 number form the stream per object in the trigger, and now you are using 2 numbers per object.

I hope this makes sense.

0 ·

Claire Krupp commented · Dec 11, 2019 at 02:54 PM

thanks @Braydn T I will play around with that when I get the chance. (The project I need this for is not starting right away.)

0 ·

Claire Krupp commented · Dec 11, 2019 at 02:59 PM

And yes, I know exactly WHY the colors are different, as you said

"the distribution that chooses the color and the distribution that chooses the shape are using the same random stream."

My point is that this should not be happening! If the software is going to choose the random streams automatically it should not be "double dipping" like this as it could make the model behavior unrepeatable and therefore useless as an experimentation tool!

I will know now that I need to specify the stream myself, but your less experienced users are not going to realize the problem!

0 ·

Braydn T Claire Krupp commented · Dec 12, 2019 at 05:33 PM

I spoke with the developers, and this is what they said: Using the same random stream does not affect repeat ability. That's why we can run the model over and over and have the same color and shaped box at the same time.

A skew can happen from "double dipping", but this does not matter in this case.

0 ·

question