Composite WIP vs Time by hour

Question

question

Karan asked Jan 19 2023 at 7:48 PM Karan commented Jan 20 2023 at 10:36 PM

Composite WIP vs Time by hour

I created a custom statistics collector for a group of Queues where the contents/WIP is recorded at the end of every hour, however, I would like to use similar logic on a Composite WIP vs Time chart so that I can see the WIP between specified stations at the end of every hour through the simulation.

In the attached model there is a custom statistics collector that I created. I tried to look at the statistics collectors behind the composite chart but I don't think I understand how it works so not sure where to start.

ContentByHour.fsm

Could someone help me out or point me in the right direction?

Software Version:

FlexSim 22.2.2

dashboards statistics collector queue content

contentbyhour.fsm (71.4 KiB)

Answer 1 · 2023-01-20T07:47:11Z

Felix Möhlmann answered Jan 20 2023 at 7:47 AM Karan commented Jan 20 2023 at 10:36 PM

The composite WIP chart uses two statistics collectors and two groups to gather the data. The two groups hold the Entrance and Exit objects respectively.

The Core Collector listens for entries into these objects, with different events for differenty types of objects (Fixed Resource, Process Flow activity, Task Executer, ...) because they require slightly different logic to handle the object types.

When an item enters an "Entrance Object" a new row is created with the item being used as the row value. This row only contains the time at which the event happened. When an item enters of the "Exit Objects" an a row already exists for that item, the row is "finished" (closed for further modification).

The second collector reacts to the events of the Core Collector. But first it creates a row for the row value "1" on reset and then again when the warmup time elapses. At the same time, a label "WIP" is created for the row and set to 0.

When the Core Collector creates a new row (item enters Entrance Object), a new row with the same row value is created and the label value is incremented by 1 and used to write the current content to the row. (The rows are all immediately finished, so using the same row value again will create a new row. The label is bound to the row value though, so it can be used to keep track of the content).

Then the Core Collector finishes a row, the same is done, but the row label is decremented.

The base chart uses this system to work with any object in FlexSim. For your purpose you can use a less flexible but simpler approach with only a single Statistics Collector.

It would have three events: An item entering an Entrance Object, an item entering an Exit Object (or exiting, depends on personal preference), and the hourly timer. Only the timer will actually create rows, the other events are only used to update a label on the collector that holds the current WIP value.

In order to not have the other events create rows, their "condition" field has to return false/0. But before we return that value, we can use the field to insert code that increments/decrements the label value, depending on which event is fired.

The hourly timer event then writes the current time and the current value of the label to a new row.

contentbyhour_fm.fsm

1674200820355.png (18.1 KiB)

contentbyhour-fm.fsm (44.3 KiB)

· 3

Karan commented · Jan 20 2023 at 4:26 PM

Thank you for the detailed explanation and the solution @Felix Möhlmann! This is perfect. I had a couple follow up questions to improve my understanding:

Why is it that I don't need everything from the Core stats collector? Is that because of how simple my example model was with just queues and processors? I plan on using this in much larger models too, where there would be conveyors, combiners, etc. should I take that into account for robustness?
The second stats collector had the reset and warmup time events, why is that not needed in our case here?
Is there a way to save this stats collector in a custom user library or something of that sort so I can reuse it in different models?
Probably a stretch: Is there any way to get the input field to show as well so that the entry and exit objects could be changed easily? I thought of using parameters but doesn't look like they can be an input to the "Object" field in a stats collector.

Thank you again.

0 ·

1674228068579.png (22.4 KiB)

Felix Möhlmann Karan commented · Jan 20 2023 at 5:26 PM

1. The key difference is that my example doesn't actually use the item reference from the entry events. Which parameter refers to the entering object can be different between types of objects. Which is why, I believe, the Core Collector uses different events for each type.

Here, the events are only registered as having happened, incrementing or decrementing the label as a result, but none of their parameters are used. As such, a distinction between the object types should not be necessary.

2. These events initialize the row and its label. Since the label is defined on the collector in my example, it will be reset to 0 on reset because the respective option on the Labels tab is checked and will not be lost when the collector's table is cleared on warmup.

3. I'm not 100% sure but I don't think toolbox objects can be saved to a user library. You could just keep a (otherwise empty) model with the collector and copy its node from the model tree into other models. (Add a collector to the new model first, then copy the node from the stored model and paste it over the added collector. Any references to objects in the model would have to redone.)

4. For this I would copy what the default collector does: Define groups that hold the Entrance and Exit objects and listen to the OnEntry event on those groups.

0 ·

Karan Felix Möhlmann commented · Jan 20 2023 at 10:36 PM

Thank you Felix!

0 ·

question