consumer loop slowing down producer loop

[pschmal2]

Hi All,

I'm currently using a PXI to send commands to a chip, then retrieve the results with a DAQ. This process loops to populate a 256x50 array of values.

Each time the loop is fully populated, I want to display the result onto a 3D plot, using 3d plot lvclass and plot helper. I noticed through the profiler and using timing functions in the loop that the 3D plot would take ~200 ms to update. The array would fully populate in about 100ms, so tripling the time to update was kind of nasty.

I put the 3d plot into a consumer loop and everything else in a producer loop. It works fine, I don't mind about dropped frames, but it was running at the same speed. Apparently whenever the consumer loop executed, it would freeze completely the producer loop.

Why is this? It seems like this fellow had the same problem:

http://forums.ni.com/t5/LabVIEW/Producer-Consumer-Loops-not-independent/td-p/1115665

But he "solved" it by removing the graph altogether. As showing the graph updating in real time is critically important, I can't just chuck it.

[Mark_Yedinak]

Can you limit how much is displayed? Is your memory increasing while you are running?

[pschmal2]

Memory does not increase while running.

I need to display most of the data. Just to see, I limited the display to a 10x10 subarray of the data. This reduced the plot update time from 200ms to 100ms. Even if I could, this doesn't solve the problem.

[Norbert_B]

Depending on your code, i find it possible that you lock the UI for some time here and there. Possibly, that lock is forcing a process connected (part of) to the producer to wait.

A possible (ellegant) solution would be to collect the data in the consumer of some time and then, maybe once a second, display those collected data.

Please remember that using property nodes to the graph repeatedly introduce slow down for the update process (redraw of UI). So if they cannot be dropped, you should use "defer panel updates" to increase performance.

Norbert

[pschmal2]

Thanks for your help Norbert.

I tried to use the 'defer panel update' property, but the plot stops refreshing altogether. The program does run fast though as if I had deleted the plot completely.

Unfortunately introducing a delay is not really an option because visitors will interact with our custom hardware and expect real time feedback on the UI. This is important because some of our visitors are the ones who supply us with the money for this work 😛

I found an interesting side effect:

When I move my mouse over the 3D Plot, [i]even when it isn't updating the consumer loop[/i] it totally locks out the producer loop. You can freeze the program indefinitely just by making circles with the mouse over the 3D plot pane.

[_Tim]

It sounds like there could possibly be a timing issue between your two loops. Are you using any timing VI’s? If you are, could you post a screenshot of your loops, particularly the timing sections, so we can take a look?

[Mark_Yedinak]

Do your loops share any common VIs such as a action engine VI? If so, if they are not reentrant than they will be blocking calls and each loop will have to wait until the other is finished running the VI. This is not much of an issue if the VI is very fast however it can add significant delays if it is more intense processing.

[pschmal2]

My consumer loop is only the 3D Graph with the plot helper.

My other loop has two DAQmx functions, one write and one read for the two different PXI modules I'm using. The loop also has some MathScript boxes to solve a least squares problem, and a FFT block from the LabVIEW base library. There is a timing structure to make sure the write DAQ function finishes before the read DAQ function.

I don't know about action engines. When I look at the profiler maybe the top 10 time users all have something to do with 3dlvclass. Is this considered an action engine?

[Mark_Yedinak]

No, an action engine is sometimes called a LabVIEW 2 Style global. They are basically a VI with a while loop and an unitialized shift register. They are useful when passing large amounts of data since it does not get copied. Also if you have transformations that are made on the data it is a single self contained VI that has data and actions which can be performed on it. Today a LVOOP implementation would be prefered. At any rate, this is a non-reentrant VI which will cause blocking to occur if called from two or more loops at the same time.

Out of curiosity, what type of graphics card do you have in the PC? Would a better graphics card help?

[pschmal2]

I'm using a PXIe-8101 controller right now. I have on order a PXIe-8135 though, and hopefully that will help.