LabVIEW Probing on Time Loops

Issue Details

If I put probes inside time loops this results in an imminent use of computational resources that are most of the time unnecessary. Timed loops are periodic execution commands that will deploy all the tasks within the loop. On the other hand, a feature like probing requires to fetch and show data at a point that is unexpected to the logic of a regular VI. Thus the usage of the probing resource within a timed loop, such for, case or while, heavily impacts the use of computational resources and typically is reflected as a delayed execution, lag within the running code or ultimately a timeout error if the loop is long. 

Solution

The natural and best solution for this is to avoid probing within a loop structure. Probing can be done outside the loop and for most of the cases won't reflect negatively on the task for which probing is being used. However, if probing is strictly necessary to be done within the loop, these are the best practices for probing within a loop:

• Ensure that data is not being held for many cycles and thus taking up significant memory resources.
• Probe only where it is strictly necessary to avoid duplicate probing.
• Probe at lower execution speeds if possible to help reduce buffering and timeout issues.
• Don't probe specifically to troubleshoot  LabVIEW errors, there are other resources like retaining wire values or doing highlighted execution that are meant for code troubleshooting and won't have any negative effect on loop structures.

Additional Information

These negative effects are specially significant when using LabVIEW while relating the VIs with other software like NI Digital Pattern Editor, or InstrumentStudio, which handle high volume of memory and processing resources. Another adverse effect on this practice is that it will also disrupt hardware-timed operations, so it is specially necessary to avoid probing on timed loops if the operations are hardware-timed.