Tracked variable rounding problem

Question

question

Patrick Zweekhorst asked Feb 26, '24 Jordan Johnson commented Mar 7, '24

Tracked variable rounding problem

Hi,

In the attached example model a kinetic tracked variable is created with a rate of 1. The token then enters a wait for event activity that waits for the tracked variable to change to or trough the value 1. After 1 second the rate is set to 0.

The tracked variable is at value 1 now, but the token did not fall out of the wait for event.
It looks like when the rate is set to 0 that the event is removed from the event list, although the event would have fired at the same time.

The attached model is a small sample model for a big model where we noticed the same problem.

Would you classify this as a bug? Or is there maybe a work around for now?

Thank you in advance,

Patrick

KineticLevelCrossEvent.fsm

Software Version:

FlexSim 24.0.1

wait for event trackedvariable timing

kineticlevelcrossevent.fsm (35.0 KiB)

Answer 1 · 2024-02-27T21:03:37Z

Jeanette F answered Feb 27, '24 Jordan Johnson commented Mar 7, '24

Hello @Patrick Zweekhorst,

Placing a Breathe activity before setting the rate to 0 fixes the timing issue in your demo model. Is the same true for you original model?

I will send this into the development team. I think this is a bug.

1709067814486.png (84.2 KiB)

· 4

Patrick Zweekhorst commented · Feb 28 at 09:08 AM

Hi @Jeanette F ,

In this example it indeed solves the issue. To create the example we intentionally added the breathe on the left to get the example. In the actual model we have much less control on the sequence of the events, so it is not a solution in that case. Looking forward to what the development team thinks.

Thanks

0 ·

Jordan Johnson ♦♦ commented · Mar 06 at 10:27 PM

Hi Patrick, this seems to be by design. The Tracked Variable doesn't believe it has arrived at the value at that point because it didn't execute its "value arrived" event. I don't anticipate we will change this. As a workaround, consider using an extremely small rate instead of zero. In this example model, if I set the rate to 1e-9 (which is valid FlexScript) then the token falls out as expected.

0 ·

Patrick Zweekhorst Jordan Johnson ♦♦ commented · Mar 07 at 09:01 AM

@Jordan Johnson ,

Thank you for the response. However I don't have control in the first actual model where we found this problem. This example model was just to create a similar scenario. In the actual model it is FloWorks controlling the rates, so I can't (of course we can modify FloWorks) control the rates.

I still think it is strange that the event is scheduled on this time, (changing the breathe, changes the event sequences and changes whether the tracked variable arrives at the value). So that would point to the conclusion that the tracked variable is at the value, just the event has not fired. When the rate is set to 0, the event is cancelled. In FloWorks we sometimes also have things like this where we check if the event would have fired at the same time, and if that is the case we still fire that event.

Any thoughts on this would be appreciated.

Patrick

0 ·

Jordan Johnson ♦♦ Patrick Zweekhorst commented · Mar 07 at 08:41 PM

I get that it seems strange, but we don't plan to change the design. The best course is to help the user avoid the situation using a breathe or by adding a tiny amount to a hard coded delay, or by listening to a different event all together.

0 ·

question