Producer Consumer Loops not independent?

[noli]

Hi,

  I have the following block diagram (vi snippet) where I try to do an NI scope acquisition in a producer loop, and show the graph in a consumer loop.  When I display the data on the graph in the consumer loop, it "seems" to slow down the  producer loop which updates a counter, however when I disable the graph in the consumer loop, things seem to run at full speed.

Isn't this exactly what is NOT supposed to happen?  What am I missing here?

Thanks

[RavensFan]

My guess.

You are using a lot of property nodes in your producer loop which all must go through the UI thread.  The updating of the graph in the consumer loop slows down the UI thread making all of those other property nodes run slower.  When you disable the graph, there isn't as much work for the UI thread to do and the property nodes are able to keep up.

Why are you using so many property nodes?

[noli]

They're actually local variables, (I don't know why the VI snippet function shows them as property nodes)  and I use them to pass information between the two loops -stop buttons, counter values.. etc..

Is there a better way?  

[F._Schubert]

I don't see a performance blocker in the code yet. Maybe you can better post a picture instead of the snippet, so we don't get all these property nodes (it's a known bug of snippets).

I see some issues in your consumer loop:

* error wire needs a shift register.

* instead of checking for the # elements in the queue, just try to dequeue without any timout.

* Destroy the queue when your producer is finished, this will generate error 1122 or 1 in the dequeue function. Stop the loop if an error occurs. Cancle errors 1122 and 1 (you want to propagate other error codes). This way you can use a latched boolean for the stop button and get rid of some locals.

Felix 

[jcarmody]

---

F. Schubert wrote:

[...] (it's a known bug of snippets) [...]
 

---

It's a known bug with native LabVIEW snippets; the Code Capture Tool doesn't do it.

[noli]

Thanks for the tips, I made the changed you mentioned felix, but the problem is still there.  The explanation about hte UI thread makes sense..  so its just the UI that's slow, but the transfer of data from my card to computer still happens at the normal speed (ie, the producer loop)?

[F._Schubert]

The graphs have some option called 'syncronous display'. My benchmarks (but in LV 7.1) have shown that it's better to leave this unchecked (the default). Maybe you have it accidentially checked.

If you try to display unreasonable large data sets (unreasonable is 10k points and more, 'cause You don't have the pixels to display them), the performance suffers as well.

Looking at the code, I would say, it's the write to spreadsheat vi that will use most time (because of the HD speed).

You can try running the 'Profile VIs..' (on 7.1 it's hidden in Tools->Advanced), there is an option 'Timing Details' that will give two entrys 'display' and 'draw' that should get a high number if it is the graph drawing. Also you can check if the load is unequally balanced on your cores using Win task manager.

One more idea to look for: Is there any Control/Indicator/Decoration on top of the graph or under it? That also kills performance.

Felix

[noli]

Ok,  Changing the synchronous display property didn't change anything, so I must still have too many things clogging my UI thread somehow.  I guess I'll just have to not display the data on the screen.  Thanks everyone for all of your tips!