Using Time Tables with Process Flow activities

[MBJEBZSRG]

Is there a way to use Time Tables to control Token Source Activities in Process Flow? Currently I am creating tokens with a Interarrival Token Source, but I would like to control the Token Source with a Time Table in the same way I would a Flow Item Source, but apparently Process Flow activities are not supported by the Time Table. I considered writing some code in the OnDown event of the Time Table, but I am not even sure the stopobject() command works on Process Flow activities, so whats is the alternative?

[sam_stubbsYXX86]

So time tables are used to mark when objects or "Down" or "Resuming." If you want process flow to be triggered in correlation to one of these triggers, you can can use an Event-Triggered Source. If you open up your Time Table properties, under the functions tab, you can actually use the eyedropper from the Event-Triggered Resource to "sample" the On Down or On Resume triggers. This will let you use those triggers from the Time Table to generate tokens and use in a Process Flow.

I'll also include a very simple model illustrating this in practice.

processflowtimetable.fsm

[MBJEBZSRG · Accepted solution]

Thanks Sam, but unfortunately this doesnt quite solve my problem since I want to control individual processflow activities with the Time Table.

Its a bit complicated but I may have found a work around though: By using the new preemption activities I have created a flow that spawns tokens and can be preempted when the Time Table dictates it.

In the above flow the Delay activity would be the interarrival delay. When the Time Table OnDown event occurs it would spawn a token in the "Preempt" activity, which will save the state of the token in the Delay activity and then release it to the Preempted Tokens activity. When the OnResume event of the Time Table occurs it will spawn a token in the End Preempt activity and the token in Preempted Tokens will be restored to the Dealy activity.

Having all this replace a single Interarrivel Source activity seems a bit excessive but its the most elegant way to control the flow of tokens that I can think of. Let me know if you anyone has a better idea.

[christian_norregaard]

Nice solution, Martin.

[Brandon_Peterson]

Martin,

Another solution would be to have your time table set the state of another object in the model. This object could be either a dummy object or another object that was already part of the same time table as the source. In your current model you can place a decision point after the process flow source that looks at the state of the other object. If the state is "Up" then the token would continue on the previous path. If the state is "Down" then the token would be diverted to a sink.

One side effect of this solution is that the source is not delayed like it would be in the traditional way. Rather, the flowitems are just skipped. For example, if the source was going to produce a flowitem in 15 seconds when the down event occurs the traditional approach would produce a flowitem 15 seconds after the resume event. This methods would produce a flowitem 15 seconds into the down event and send it to the sink. It would then continue to produce flowitems at the previous interval (all of which would go to the sink) until the resume event. Based on the interval of the source and all the randomness of the system the next flowitem would be produced at ??? seconds after the resume event.

If that side effect won't have a significant impact on your model then this may be a more simple approach for you. If it does have a significant impact on your model then I would recommend an approach more similar to the one you gave above.

Good Luck,

Brandon