Helper Loop periodic timing
What’s a Helper Loop?
A Helper Loop, in the DQMH framework context, is the name given to a loop executing code periodically through the Timeout case of an event structure.
You can implement a Helper Loop even if you are not using the DQMH framework |
A Helper Loop is composed of the following elements:
-
A while loop.
-
An event structure with the
Timeout
case. -
A non-negative value set to the
Timeout
input of the event structure.
The code you want to execute periodically is put into the Timeout
case.
Using the Helper Loop periodic timing API, the code is transformed, shown below picture, with the following main advantages:
-
Steady period execution of the
Timeout
case. -
Late execution information available.
The steadiness of the period execution is relative. Depending on the OS, the overall usage, the code executed in the Helper Loop… the real period can be randomly shorter or longer than the one you expect. |
if you want to explore the Helper Loop concept and why it’s a better solution than self-messaging, take a look at this excellent article |
How the Timeout case execution is triggered
The Timeout
case is executed when no events are detected during the time set to the Timeout
input of the event structure.
The Timeout
counting starts when the event structure is called.
The time spent executing code in the Timeout
case and after the event structure execution is delaying the next Timeout count.
Any event occurring reset the Timeout count.
The Timeout
case can be rarely (or never) executed when the event structure handles other events.
That’s why, setting a value to the Timeout
input of the event structure is not enough to get a steady execution period of the Timeout
case.
How the Helper Loop timing API ensure a steady period
Using the API to time your event structure allows you to:
-
get a steady execution period in any case.
-
know you are late executing the
Timeout
case.
The example provided demonstrates the different issues that can occur.
The Helper Loop are set to execute the Timeout case every 250 ms
|
Timeout reset
1 | Hitting the Reset Timeout button triggers an event in the event structure. |
2 | In the incorrectly timed Helper Loop, the execution time is impacted by the reset. |
3 | In the correctly timed Helper Loop, the Timeout value is modified to take account of the reset. |
4 | The execution time is not impacted. |
You can see that the incorrectly timed Helper Loop executes fewer times than the correctly timed one. |
Timeout case time execution
1 | We simulate a code execution taking 100 ms. |
2 | In the incorrectly timed Helper Loop, the execution time is impacted by this code execution time. |
3 | In the correctly timed Helper Loop, the Timeout value is modified to take account of the time spent since the beginning of the Timeout case execution. |
4 | The execution time is not impacted. |
Late Timeout case execution
Even if you time your Helper Loop correctly, you can get late execution of the Timeout
case.
Indeed, if the code that executes after the beginning of the Timeout
case execution takes more time than the desired period, there’s nothing to do.
The API provides a simple way to monitor if your Helper Loop runs at the expected period.
1 | We simulate a code execution taking more than the desired period. |
2 | The period execution cannot be reached. |
How the Helper Loop timing API handles late execution
The API provides three modes to handle late executions.
No change
This mode will try to make sure that the drift will remain equal to 0 even if some late execution occurs.
What’s the timing behavior when a periodic execution starts
-
When the
Helper Loop Periodic Timing
object is initialized, theTimeout
case is not called (i.e. TImeout is set to -1). -
When a Helper Loop period is set, by default the first execution of the
Timeout
case will occur as soon as possible. -
You can ask the API to execute the first
Timeout
case after the period set time has elapsed
The function Get Timeout offers an output to let you know when the execution of the Timeout case is the first execution after a Helper Loop period change. This could be useful to execute some Initialisation code.
|
An example is provided with the API to observe the behavior of the modification of the Helper Loop period.
How to execute a finite number of iterations
Helper loops generally run continuously. They are stopped on events (user interaction, measurement process…).
In some cases, you may want to execute a finite number of iterations. The API allows you to do that with an optional setting of the Set Helper Loop Period function.
Deprecated functions
v1.3.0
To introduce new features, 2 functions (Init Helper Loop Info and Update Last Execution Time) has been deprecated due to icon pattern change.
To avoid breaking codes developed with earlier versions, those functions are still present in the library but no longer displayed in the function palette |
Icons of deprecated VIs are surrounded by a red box:
To get ride of those function, replace them by the new versions available in the palette.
You can keep deprecated functions in your code. The code will behave normally. You’ll just not be able to use some new features |
Going further with LabVIEW Events
Using Daqmx Events for continuous tasks
It’s a feature too often underestimated or even not known by LabVIEW developers, but you can register an event structure with Daqmx events.
there is a known issue that may crash LabVIEW in certain situations. The way to avoid it is described here. |
LabVIEW events set of examples
To dive more into the event technology provided in LabVIEW, you can glance at the set of examples provided in this open-source project.
The presentation of those examples is available: