RT FIFO hard polls with a '-1' timeout waiting for a command during engine initialization

[Beazurt]

This uses up more CPU than needed and can cause extreme initialization delays on a single-core controller.

[ramezanifar]

Thank you for your effort. Now that you found this issue, do I need to wait for a release of the framework or is it already fixed?

[Beazurt]

This issue is still 'Open'. Once a fix makes it into the source it will be set to 'Closed'. At that point it will take more time to create and release a new build. This process should take a full week at minimum, but we can't guarantee a worst-case delivery time. If you need a short-term fix, you could change the RT FIFO mode in the Standard Engine 'Open' VI to 'Interrupt' instead of 'Polling' and see if that fixes the problem.

[pollockm]

FYI, I have a fix in testing now.

There are two possible solutions: change the read method to blocking instead of polling or add a sleep to the initial startup check.

I need to verify which of the two possible solutions has minimal impact on performance of the framework. Should take another day or two to finalize the change. I'm targeting end of week for a release, subject to change if testing shows issues.

[pollockm]

Went with second option (add sleep logic to initial startup code, leave runtime execution as-is), since it was the lower-risk change. Runtime performance after initialization is stable, initialization time on a 9014 is now <10 seconds. You'll still likely see the LV environment disconnect during initialization, which is completely normal on the single-core targets when their CPU usage is maximized. You can reconnect in the environment or increase the disconnection timeout. Increasing the disconnection timeout can be done in the properties dialog for the RT target:

[ramezanifar]

Thank you very much for the fixes. Can you please notify me when the update for DECAF which includes the new fixes is available?