Automatically calculating touch time with custom code

Question

question

Kathryn McNeal asked Sep 5, '17 Jordan Johnson answered Sep 5, '17

Automatically calculating touch time with custom code

I have created code that can be quickly added to a complex model to calculate touch time (only where operators are required). The only time it doesn't seem to work is when you are using the label on an item to calculate your setup and/or process time (which we do in some of our models).

Explanation of model:

A "touchtime" label is set on the item creation in the source. All of the processors, combiners, and separators are added to the "Processors" group. The process flow has an event triggered source that is triggered anytime an item exits one of the objects in the "Processors" group, and adds the item name and processor name to labels on the token. The custom code is well commented, but it adds the setup and/or process times to the "touchtime" label on the 3D item.

There are four different examples (finish queues for Type A, B, C, D):

Type A - uses a distribution (works)
Type B - on entry to processor sets "itemSetupTime" label, then uses that label to identify the setup time. (doesn't work)
Type C - splits the touch time across the units in the tote (works)
Type D - no touch time (works)

Explanation of problem:

On lines 22 and 28 of the custom code in the process flow, the custom code is executing the code in the processor's setup time and process time. Because it is not the processor that is executing the code, the "current" and "item" variables are not set correctly. (Note - I realize that if it executes a distribution, it will pull a different value from the distribution than the actual 3D model did. This is not ideal, but is acceptable.)

Question:

Is there a way around this? Is it possible in process flow to access the actual value that was returned in the processor's setup/process code? This would be better all around as it would solve my problem and make the label touch time reflect that specific item's actual touch time. I could have separate event triggered sources for the setup and process times if separate triggers are needed.

For this to be useful for us, we need to avoid making any changes to the processors/the processor's code since there are large numbers of processors in our models. Ideally all of the code will be in process flow that can be applied to all of the items in the group "Processors".

Software Version:

FlexSim 17.0.4

process flow event-triggered source

track-touchtime.fsm (32.2 KiB)

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 · 2017-09-05T21:57:13Z

Jordan Johnson answered Sep 5, '17

Here's my solution (track-touchtime.fsm). The basic idea is to listen to when the item begins setup, and remember the time. Then, when the setup finishes, subtract the start time from the current time. This method is repeated for the process time. However, because of the tote situation, along with only tracking time for things that require operators, makes this a little tricky:

First, there are for Event Triggered Source activities. They are all listening to all objects in the Processors group. They are fired when the setup time begins (Setup Time), when the setup finished (On Setup Finish), when the process time begins (Process Time), and when the process finished (On Process Finish).

When an item hits the first of these landmarks, Setup Time, we create a token for that item or tote. The Set Divisor activity sets a label called "divisor" to 1. Then, we use a Decide activity to determine whether we are dealing with an individual item or a tote, based on whether there are any items inside the item. If it's a tote, we'll create a token for every item in the tote, and set the item and divisor labels to new values:

Notice that I overwrite the "item" label on all the new tokens, each referencing one of the items in the tote. Also, I overwrite the "divisor" label so that it will now contain the number of items in the tote.

Next, I create a reference to the current token on the item, so that the item knows which token it is associated with:

Notice that I am assigning a label to the item, not to the token.

Now that the item is linked to the token, the token saves off the current time, and then goes to a decide that is set to Do Not Release Token. You may be wondering how the token eventually gets released, if the decide doesn't release it. This is where the other Event Triggered Sources come in. Whenever any of the other landmark events occurs for an item, that token releases the __stats_token__ for that item.

Note: Instead of using a Decide that doesn't release, along with another Event Triggered Source, I could have used a Wait For Event, and made sure to match the item label. However, that method gets slower and slower as the number of processors grows.

Also Note: If a token enters a Source activity, it just passes through, without updating any labels.

So once a token is released, we figure out if an Operator was involved in the current step. If it was, we add the time to the touchtime on the item. If not, then we just move on to the next step.

Hopefully, this does what you want. Let me know if you have any questions!

track-touch.png (74.8 KiB)

track-touch-create-tokens.png (23.4 KiB)

track-touch-link-item.png (12.6 KiB)

track-touchtime.fsm (37.9 KiB)

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.

question