Solution
This behavior is expected and is caused because the owning VI runs in a single thread and continuously creates data change events to the XControl. The XControl responds to the data change events in another thread, similar to a producer/consumer architecture. The consumer runs slower than the producer since a large number of matrix calculations and object redraws take more time than a single loop. The XControl buffers the data change events and responds to them sequentially. Even when the owning VI stops, the XControl is still running until it responds to all events, since they are running in different threads.
There are several workarounds and recommendations to avoid this behavior.
- Do not use the indicator within a loop. Plot the data to the indicator after the loop has completed.
- If you must use the indicator in a loop, use the Wait function to slow the loop iteration.
- Avoid other User Interface operations within the loop or in parallel.
- Do not use the indicator with large data sets.
- If you have a large data set, decimate the data before sending it to the indicator. For example, average adjacent points and send the average to the indicator.
- Avoid calls to the LabVIEW Memory Manager within the loop. Such calls are made when using certain array functions. See VI Memory Usage for more information.
- The performance of the indicator is system-dependent. Be sure to consider the development system's capabilities with respect to the deployment systems when programming.