question

Tom S4 avatar image
0 Likes"
Tom S4 asked Jordan Johnson commented

ProcessFlow: Wait for Event, match the state it is changing "from"

My understanding is that when waiting for a state change event, the new state value can be accessed (matched, assigned, etc). Is there a method to access the old value?

FlexSim 21.1.5
processflowstatesevent trigger
· 1
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Tom S4 avatar image Tom S4 commented ·

I just realized this is only an issue for custom objects. There is the option for profile, to, and from on a normal processor. But with a custom FR there is only profile and state.

0 Likes 0 ·

1 Answer

Jason Lightfoot avatar image
1 Like"
Jason Lightfoot answered Jordan Johnson commented

When the event is triggered the state on the BasicFR object is still the old state, so you can detect the new and old.

· 2
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Tom S4 avatar image Tom S4 commented ·

Hi Jason. Thank you for the response.

Are there plans to add to/from to the event params in the future? Right now I don't see any other way to match 'from' without triggering on every state change and checking current state in a separate block, which I imagine would be a hit to performance as tokens need to be created and more events are added to the event queue.

I've attached an example model for the solution I'm thinking.

Example State Change Model.fsm

0 Likes 0 ·
Jordan Johnson avatar image Jordan Johnson ♦♦ Tom S4 commented ·

The old value is exposed in the On State Value Change event, or in the OnChange event of the state profile, if you listen to that directly. However, the UI for the Wait for Event or Event Triggered Source shows the Tracked Variable event UI, which doesn't let you work with the old value. You can set up a custom listener, if you really need those values. But it's usually bad practice to try to define model logic based on state change, for two reasons:

  1. Objects frequently go into states for zero time. For example, when an item arrives at a Processor, the Processor will enter the setup state, even if the setup time is zero. In addition, when the item leaves, the Processor will enter the Blocked state, even if the item is blocked for zero time.
  2. The state change event is fired in response to resetting the model, as well as stopping the model. There are probably other UI-level events that cause that event to fire.

Usually, there's some other approach that avoids all of these issues. I'd recommend looking for some other approach. If you post a new question, and explain why you needed the old value (along with a demo model), we may be able to help you find a better alternative.

0 Likes 0 ·