When does an Event-Triggered Source OnStateChange create tokens

Question

question

David Besson asked Nov 22, '17 David Besson commented Jan 8, '18

When does an Event-Triggered Source OnStateChange create tokens

I am not sure to understand when the Event-Triggered Source create tokens while the event is "OnStateChange".

It seems that a token is created when the model is reset or stopped. Is it supposed to work in this way?

If I want to create a token when the state (processing, idle, etc.) of the object change, should I use the "OnStateValueChange" event?. But with this event, I have 2 limitations:

The event data (State profile No, To State, etc.) are not available anymore
only the default state profile seems to trigger the source

Attached a model to illustrate it.

Thanks for your help.

eventsource-onstatechange.fsm

Software Version:

FlexSim 17.2.3

process flow event-triggered source onstatechange

eventsource-onstatechange.fsm (19.7 KiB)

· 2

David Besson commented · Jan 08, 2018 at 11:14 AM

and please note that to change the state of an object you should use:

Object.setState( int state , int stateProfile )

and not:

Object.stats.state( int stateProfile ).value = ( int state )

1 ·

Jeff Nordgren commented · Nov 30, 2017 at 07:55 PM

@David Besson

Did you get an answer to your question?

0 ·

Answer 1 · 2017-11-30T21:14:32Z

Phil BoBo answered Nov 30, '17 Phil BoBo edited Nov 30, '17

OnStateChange fires whenever setstate() is called on the object, even if it being set to the same state that it is already in (such as what happens when you press the Stop button and it updates the state statistics on all the objects in the model). (In OnReset, the object is probably setting its state to idle.)

OnStateChange happens A LOT. It may get called several times within 0 seconds to states that it won't be in for more than 0 seconds.

If you want to write your logic based on whenever an object gets its state set with setstate(), then you are welcome to listen to OnStateChange, but you need to write your logic accordingly, which can get complicated. It is almost always better to write your logic elsewhere.

OnStateValueChange listens to the TrackedVariable that stores the state information. This is subtly different and works the same as listening to any TrackedVariable in the tree, not just the State TrackedVariable. This also gives you a Change Rule so that you can have it fire at specific times rather than every single change.

You can sample the other profiles in the tree to listen to when their value changes. For example, MODEL:/MultiProcessor1>stats/state_profiles/MultiProcessor States.

A better way to write logic for objects is almost always in a different trigger, not in OnStateChange or OnStateValueChange. Those events should be used for recording output related to states, not object logic.

question