State after wait for state change to utilize not utilize

Question

question

Patrick Zweekhorst asked Aug 29, '17 Phil BoBo answered Sep 15, '17

State after wait for state change to utilize not utilize

Hi,

I have made a simple example model where I have a custom code activity in which there is a travel task (to the current location of the operator, so not important ) and a utilize task. After this custom code activity I have a wait for event in which I wait on a state change to state utilize. After this wait for event I want to free the operator with the freeoperators command. The problem is that the operator is not in the state utilize after the wait for event.

Is this again something with synchronisation or is this a bug?

It works if I put a delay after the wait for event, but it feels kind of strange to do this after a wait for event. The example model in built in the 17.2 beta, but the same thing occurs in 17.1.utilizebug.fsm

Thanks,

Patrick

Software Version:

FlexSim 17.1.4

wait for event utilize operator freeoperator

utilizebug.fsm (20.2 KiB)

Answer 1 · 2017-09-15T14:23:08Z

Phil BoBo answered Sep 15, '17

"but it feels kind of strange to do this after a wait for event"

That's not strange at all. You often need 0 delays after a Wait for Event activity because the subsequent logic needs to wait until the code executing that event completely finishes before moving on.

The documentation of the Delay activity somewhat explains this usage:

"Using Delays as Breathes

A breathe, which is a delay time of 0, is similar to sending a delayed message in 0 time. Doing so will create an event in 0 time before releasing the token. Breathes can allow you to break up certain operations to ensure that things are happening in an appropriate order. This is like taking a breath before moving on. It may be difficult to know when this is needed, but if something in your model is not behaving properly, adding a breathe can potentially solve issues."

You very often need a Breathe activity after a Wait For Event activity. There is nothing strange about that.

Answer 2 · 2017-08-29T14:44:44Z

Joerg Vogel answered Aug 29, '17 Patrick Zweekhorst commented Aug 29, '17

The command freeoperators set a taskexecuter free and so into the state of being available or idle. It is inherited by its function. Or am I missing in your approach something?

· 1

Patrick Zweekhorst commented · Aug 29, 2017 at 03:00 PM

Hi,

The problem is that in the delay, after the wait for event and after the freeoperators command, the operator is not idle, but utilize. The freeoperators command is executed before the operator goes in its utilize state (although I wait until the operator gets in this state). The operator will there for not start with any other task, if you would give him one.

0 ·

question