Wait for event - Time to create a listener

[marco_baccalaro]

[ FlexSim 18.0.3 ]

In order to create a log of the items flowing trough a model, I create a token for every item that is created at reset.

I have 33617 items, so I create 33617 tokens that flow

into a "Wait for Event" activity.

Here I wait for the item's OnEntering event.

Every time a new token enters this activity and so a listener to that event is created, the real time to create this event rises grows.

This is the result of a test

• To create the first 6071 listeners, 0.02 seconds are required
• To create the next 5137 listeners, 1.38 seconds are required
• To create the next 6124 listeners, 4.73 seconds are required
• To create the next 5085 listeners, 15.99 seconds are required
• To create the next 6097 listeners, 21.20 seconds are required
• To create the next 5103 listeners, 34.28 seconds are required

Seems that every time a token enters this activity, some code is executed for all the other tokens already there (e.g. all listeners are created again)

Is there a way to speed up this operation?

Thank you.

[steven_hamoen]

@Marco Baccalaro I think FlexSim should answer why it gets so slow but wouldn't a simple solution be:

1. Create the token when something enters the pallets (so use an event triggered source instead of a wait for event)

2. or use a zone that only allows one token into the wait for event at a time. (I guess that only 1 product at a time is entering the satellite)

[marco_baccalaro]

Off course I can change the whole solution, but this one is very simple to me because I have also multiple satellites, and after that step, the token goes to another "Wait for event" activity where it waits to exit the satellites and so on. The token has a label "row" that stores the row of the log table where I write the time the pallet entered the satellite, the time it has been unloaded by it and so on.

Except for this issue, this solution works very well to me.

[JordanLJohnson · Accepted solution]

This is probably the slowest approach you could take to getting the data you want. First, adding the events are slow, because we do a search through all listeners to make sure we don't duplicate listeners. So the longer the list of listeners gets, the slower adding another listener becomes. Second, when the event occurs, the Wait for Event must go through all items to check if the match labels actually match. This also gets slower and slower with more and more tokens.

To gather this kind of data, you could actually just use a Statistics Collector. One of the tutorials covers how to make an item log. In your case, you would listen to the Exit events you care about, and then link those events to corresponding columns. You can even record inter-column times as part of the stats collector. This approach is lightning fast (there are only three listeners created). It is also very memory efficient.

stats-collector-item-log-demo.fsm

[marco_baccalaro]

Thank you, I've quite understood the problem. Just another information: the check for duplicates is done on all the listeners in the model or just on all that have been created into that "Wait for Event" activity?

I think the statistical collector method is not so good in my case because I want to track items that can go anywhere: I need to listen to their OnEntering or OnExiting events and not on the objects they could flow into.

Maybe I'll directly write the code into those eventfunctions so I can create the pallets with that eventfunction only if the user activates the "pallet logging".

[JordanLJohnson]

The check for duplicates happens just on the single Wait for Event activity.

Depending on how you want to log the data, you might also consider using the Item Trace Gantt template. It listens to the OnEntering and OnExiting of each item, and then makes a Gantt chart of that data.

[marco_baccalaro]

I looked at the Item Trace Gantt template. It uses a Process Flow (MODEL:/Tools/ChartTemplates/Item Trace Gantt>stats/processFlow/Flow) and it has a "Wait for Exiting" activity that waits for OnExiting for all items so I suppose it slows down as it does the one I've built.

I'm building a module so I can use code without problems, I think I'll write everything on the OnEntering of the items. To speed up the simulation, when the log is disabled by the user, the items normally won't have this eventfunction. When the log is activated, on reset, I copy this nodefunction on the pallet in the flowitembin.

Do you think this could be a good solution?

Thank you

[JordanLJohnson]

Listening to OnExiting is very different from listening to OnExit. There is only one listener per flowitem, so the "search" for both creating the listener is only one check. Also, the number of tokens that respond to the event is only one, so there is no search there, either.

If your solution works for you, then it is a good solution.

[marco_baccalaro]

But I was listening to the OnEntering trigger of the flowitem in my first solution.

[JordanLJohnson]

Oh, I see. Then I will read the code when I get in on Monday, and figure out what's slow about it. I do know (from experience) that listening to OnExit is slower.

[joerg_vogel_HsH]

Instead of listening to all created tokens and waiting for the right item entering the model you can delay the created tokens and wait only for items entering in the next hour. The wait for event activity holds only the tokens of the next hour.

If the token doesn't match you can preempt the wanted token in delaying activity.

Alternatively you push the tokens to a list and pull only the token that must wait for the next entering event.

If the waiting token doesn't match you pulls the right token from the list and push the other back to the list.

[marco_baccalaro]

Maybe is because I'm using a General Process Flow. I could't use the Sub-Flow type because of a bug on the creation of a subnode of the "stored" attribute that overwrites the one created by Entry Transfers of the Conveyors. (I've reported the bug to the dev@flexsim.com).

Maybe a Sub-Flow, creating different instances for every token doesn't need this check on all already waiting tokens in the same activity.

[Matthew_Gillespie]

@Marco Baccalaro The overwritten stored subnode issue is fixed in 18.0.4 that was released on Friday.

[marco_baccalaro]

Good! So I've tried to change my Global Process Flow with a Sub-Flow one. I've tried to set the instance creation on the options "Per Token" or "Per Instance" instantiating the pallet. I hoped that doing this wasn't necessary to check all the listeners of the "Wait for Event" activity but the result didn't change.

No problem in my case, I'll put the log update directly on the "OnEntering" eventfunction code avoiding the process flow.