Graph update delay with two loops access the graph reference

[joezhang]

Hi all,

I'm working on a program that talks to a camera and a serial device. In the front panel, I have an intensity graph to display the image from the camera and also some numeric indicators for displaying the output from the serial device. I also need to change cursors position in the graph depending on the output from the serial device.

My program has three loops:

1. user event loop

2. camera loop to read the raw data from the camera and write to the intensity graph.

3. main loop to check the serial buffer and update front panel indicators and cursors if there is any output from the serial device. The indicator is updated every time there are new data from the serial device. The user has an option to do an average update for the cursors, meaning the program only updates the front panel cursors when accumulating a certain number of data from the serial device. I use a event loop and the timeout event is used to do the checking of the serial buffer. The fastest output from the serial devices is 10 Hz.

Then I found that if the average number is small, say 2, there is an delay in front panel update. When I stopped the serial device, the front panel could take up to 30 seconds to continue updating the front panel. If I set the average to a larger value, say 10, the front panel can keep up with the serial devices.

I am wondering if there is anything that I can do to eliminate the delay of front panel update? I would think even at the max frequency of 10 Hz, the program should keep up. So I think there is something that I didn't implement correctly. Maybe because I update the intensity graph (data and cursors) asynchronously from two loops? Any idea is welcome.

Thanks,

Joseph

[Ben]

Control terminals and locals of same can update the GUI without using he UI thread.

Control references on the other hand require the UI thread. If you have multiple loops updating a FP they will have to take turns getting at the UI thread.

One technique that MAY help is to sue the "defer.FPUpdate" property prior to applying changes and then un-defer after the update. Defer FP Updates will consolidate all of the changes while the updates are deferred and only update the GUI when the defer updates is set false.

It does not always help but it does in some situations.

Additionally... everything that uses the UI thread will have to be managed to play nice together. That includes dll's configured to run in the UI Thread.

Ben

[majoris]

Turn on Execution Highlighting maybe and see what is taking so long.

http://www.ni.com/getting-started/labview-basics/debug

You can also use the VI Performance and Memory to profile your program, though it is hard to use and interpret.

http://digital.ni.com/public.nsf/allkb/9515BF080191A32086256D670069AB68

What timeout are you using for your serial communication? Are you using a timeout in your User Event loop? I agree that the program should be trivially able to keep up with a small amount of data from a serial port and writing to the screen from a camera faster than 10Hz, even if it is through a reference. So it is likely an issue with the block diagram. It would be helpful to see it.

[joezhang]

In the camera loop, I write the camera data to the control terminals. The camera uses ActiveX control. If I hide the control, does it still update the FP?

In the main loop, I use graph control reference to update the cursors' position.

If the highest frequency is 10 Hz, I only update the one cluster of several numerical indicators and graph cursors about 10 Hz. How fast can Labview updates FP?

I will try to see if defer.FPUdate help. But the user may not be able to try soon.

Thanks,
Joseph

[joezhang]

I use some tick count to check how long it takes to do the updating. I would say it takes less than 10 ms to update the front panel if there is a output from the serial device.

Thanks for the tip about the Profile Performance and Memory. Definitely will try it next time.

I set my serial timeout to be 50 ms. If there are no data from the serial device, it just timeout.

Sorry, I wasn't clear about my program. The user event loop handles user interaction. I didn't set the timeout for the user event loop. If the user clicks a button in the FP, the user loop sends a command to the main loop via another event. The main loop has a event loop to handle commands from the user loop. It also has a timeout case to routinely check serial device for output if there is no command. I have the timeout for the event loop in the main loop to be 2 ms.

Thanks,

Joseph

[AvatarAang]

Hello, Joseph,

Can you please send screenshots or code?

[joezhang]

Unfortunately, due to company policy, I'm not allowed to post it.

But I am willing provide information to help solve the problem.

Thank you,

Joseph

[majoris]

I'm having a hard time understanding what could take a long time. 

1) Can you time each of your parallel loop iterations? Are they all going as fast as you expect?

2) Can you replace the ActiveX control with a Labview control, such as the intensity plot, image plot or an IMAQ window?

3) Are you using any other custom controls, like an XControl, that could be buggy and lock up the UI?

4) When you say there is a delay in the front panel update, what isn't updating? For instance, if you have a 4th loop and in the loop you just increment a value and display it, are you saying the UI doesn't updates to that indicator super duper fast.

[joezhang]

I just realized that there is another thing that also uses the UI thread. I also logged all the communication between the PC and the serial device. So that can update at 10 Hz.

1. I did time the main loop, which is responsible for updating the numerical indicators/communications/cursor position. It takes about 10~20 ms to update the front panel.

2. The ActiveX control is used to communicate and read data from the camera. The vendor only provides the ActiveX interface. Everything else are labview controls.

3. I don't use custom controls.

4. What happened is when I stopped the serial device, there was no input and nothing should be updating except the camera. But we noticed that all the numerical controls were still updating for another ~30 s. This tells me that the UI couldn't keep up with the input from the serial device. 

I have a feeling this is due to various part of the program occupying the UI thread. I am planing to disable parts of the code that updates UI to see where is the bottleneck.

Thank you for your inputs.

Joseph