Tracked variable rounding problem

Question

question

Patrick Zweekhorst asked Feb 26 2024 at 3:46 PM Jordan Johnson commented Mar 07 2024 at 8:41 PM

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)

______

Cookie preferences

Your privacy is important to us and so is an optimal experience. To help us customize information and build applications, we collect data about your use of this site.

May we collect and use your data?

Learn more about the Third Party Services we use and our Privacy Statement.

Strictly necessary – required for our site to work and to provide services to you

These cookies allow us to record your preferences or login information, respond to your requests or fulfill items in your shopping cart.

YES

Improve your experience – allows us to show you what is relevant to you

These cookies enable us to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we use to deliver information and experiences tailored to you. If you do not allow these cookies, some or all of these services may not be available for you.

YES

NO

Customize your advertising – permits us to offer targeted advertising to you

These cookies collect data about you based on your activities and interests in order to show you relevant ads and to track effectiveness. By collecting this data, the ads you see will be more tailored to your interests. If you do not allow these cookies, you will experience less targeted advertising.

YES

NO

Are you sure you want a less customized experience?

We can access your data only if you select "yes" for the categories on the previous screen. This lets us tailor our marketing so that it's more relevant for you. You can change your settings at any time by visiting our privacy statement

Your experience. Your choice.

We care about your privacy. The data we collect helps us understand how you use our products, what information you might be interested in, and what we can improve to make your engagement with Autodesk more rewarding.

May we collect and use your data to tailor your experience?

Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.

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

Jeanette F answered Feb 27 2024 at 9:03 PM Jordan Johnson commented Mar 07 2024 at 8:41 PM

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 2024 at 9: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 2024 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 2024 at 9: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 2024 at 8: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