Model run time is variable when the 3D view is open, but static when it isn't.

Question

question

anon-user asked Feb 9, '18 anon-user commented Feb 11, '18

Model run time is variable when the 3D view is open, but static when it isn't.

I have a model that runs for a different amount of time when I have the 3D view open despite repeat random streams being checked. However, when the 3D view is not open the model takes the same amount of time to run to completion. The time difference is anywhere from a faction of a second to tens of seconds and changes with model run speed. The model takes 1789.2 seconds to complete when the 3D view is not open, regardless of model run speed.

I have tested this on different machines and still run in to the same problem.

All operators are reset to their original positions when the model resets and all tables that seed the model are reset as well. I thought those would be the main culprits causing this, but the problem still occurs (and the fact that the model is repeatable without the 3D view open makes me think the problem is elsewhere). Are there other factors that could be causing this that I need to check?

3d view repeat random streams model run time repeatable

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.

Answer 1 · 2018-02-09T23:13:50Z

Matthew Gillespie answered Feb 9, '18 anon-user commented Feb 11, '18

What's happening is that you're placing items in processors that are set to convey the item across itself and then pulling them out again before the process time is done. When the processing time is done, the processor calls updatelocations on the item to make sure the item is in the correct spot to be picked up. Without this call to updatelocations, the item is going to be in the last place it was drawn. This is because the Convey Across option on the processor slowly moves the item across the processor every time the view draws. With the view closed the item just stays put and never moves.

In this sample model I've isolated the behavior that's causing your model to not be repeatable. You unload the item in the processor, tell the operator to wait 10 seconds, and then load the item again.

That same models shows 3 different ways to solve this issue.

Option 1 (The best one in my opinion)

Wait until the processor is actually done processing. If you move the connector from the Unload activity so it goes to the Wait for Event activity the token will listen to the Processor's OnProcessFinish event. This way the operator isn't told to load the item until the item is done processing. This makes the most sense to me since you're letting the processor do it's job and not pulling the item out prematurely. If you don't care about the process time finishing you might as well just use a Queue object.

Option 2

Call updatelocations on the processor right before you pick up the item so that the item's location is set before you travel over there.

Option 3

Turn off the Convey Across option on the processor. This will stop the processor from moving the item during its draw and thus it will always sit in the center of the object.

...

Option 4

Not shown in the model, and I mentioned it already, but use a queue instead of a processor if you're going to manually control how long the item stays in there.

You should also check out this article on model repeatability. I referred back to it while I was debugging your model.

waituntildone.fsm (27.0 KiB)

· 1

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.

anon-user commented · Feb 11, 2018 at 10:35 PM

Thanks for the help and the article!

0 ·

question