Build Array and Avoiding Buffered Allocations ... a little help here??

[DianeS]

Hello, hello!

As Ben said, most of us are not NI employees...just members of the LabVIEW community who think it's fun to try to help other community members out.  An orange bar under your name means you're not an NI employee...a blue bar means you are.

So, as you can see, I am not an NI employee.  I'm just a random individual who really likes LabVIEW and wants others to like it too.

I've attached a little example for you that I think will point you in the right direction.  I don't have time to go over your code right now, but I will do so this weekend.  My example is much simpler than yours.  🙂

Quick answers to your questions:

1.  No idea why the occurrence function exists, but I'm sure that somebody, somewhere, must love it dearly.  Your UE queue is loaded with the "initialize" case to start with, therefore that's the first case that will execute...so I'm not 100% sure why you need the occurrence?  I probably don't understand your question, but I'm pretty sure you can just eliminate it and suffer no consequences.

2.  My example shows you how to use a notifier to stop all the loops when the "stop" button is pressed.  I think you will understand when you see it.

3.  My example also shows you how you can repetitively enter your "data" state from your state machine.  Another thing you could consider -- again, shown in a VERY "quick and dirty" way in my example -- is displaying the data from your DAQ loop, and only queueing the data to the state machine loop at certain intervals, for recording.  That way you don't throttle your queue.  There are lots of good ways to accomplish this, but let's tackle that once you're comfortable with the basics of queues and notifiers.  Ok?

4.  I would display the data from your DAQ loop, and write it to file in your state machine.  And yes, I would believe how many globals you've already eliminated.  I feel for you.

5.  This isn't so much a critical issue, but be careful of running one of the loops much faster than the others.  If you want to do that, restrict the size of your data queue so as not to overload it.

I think you're moving in the right direction and I admire the fact that you clearly want to learn this stuff, and are willing to try things out and post when you get stuck.  I hope my example program helps you a little bit.  Post back with questions on it if you have them -- I tried to add comments to help you read it.

[Mark_Yedinak]

One thing you should do to make sure your application is maintainable is to use either a typedefed cluster for the data element of your queue. I generally like to have a cluster consisting of a message ID, usually a typedefed ENUM, and either a typedefed cluster for the data or a variant. The variant is the most flexible and will allow any type of data to be passed. The recevied needs to know know how to interpret the data but that is where the message ID comes into play. Using this approach makes it easy to add new messages in the future.

[Mark_Yedinak]

---

DianeS wrote:

Quick answers to your questions:

1.  No idea why the occurrence function exists, but I'm sure that somebody, somewhere, must love it dearly.  Your UE queue is loaded with the "initialize" case to start with, therefore that's the first case that will execute...so I'm not 100% sure why you need the occurrence?  I probably don't understand your question, but I'm pretty sure you can just eliminate it and suffer no consequences.

4.  I would display the data from your DAQ loop, and write it to file in your state machine.  And yes, I would believe how many globals you've already eliminated.  I feel for you.

5.  This isn't so much a critical issue, but be careful of running one of the loops much faster than the others.  If you want to do that, restrict the size of your data queue so as not to overload it.

---

The answer to #1 is that occurances are hold over from the days when LabVIEW did not have queues or notifiers. The occurance was the only way to synchronize two parallel tasks without polling on some data such as a local, global or a functional global. They exist for backward compatibility and that is why NI recommends that they not be used. There are much better ways to achieve synchronization now.

You may still want to use a separate task for displaying the data. If you display the data from the same task where you are reading it that task will end up in the UI thread. This could impact your performance. In addition, if you have large amounts of data it can take a significant time to display the data which could negatively affect your reading of the data.

Beginning in LabVIEW 8.6 you could define your queue as lossy. If it would be OK for you to miss some data then you could set a maximum queue size and when and if that size is hit you the queue would push the oldest data out of the queue. This would result in data loss but in some cases this would be OK.

[DianeS]

I'm with you on the typedef'd cluster, Mark...I do the same thing.  I didn't in this example because I was pressed for time and wanted to get him something that would help him quickly.  I, too, am fond of using an enum (which is another typedef) and a variant in a cluster.

So you mean that, probably, there is NOT someone out there who loves occurrences dearly?

I'm crushed. 

Good point about the UI thread and the displayed data -- I guess we don't really know how much data we are talking about here.  I've always found it to be fine in terms of performance, but certainly there are cases where that would not be true.

I guess I'm trying to instill comfort with the basic concepts of synchronization and code design before worrying about where to put the data indicators -- too many concepts at once can be really confusing and hinder learning, I think.

[jonathanupr]

Thanks for the example.  I would be looking to log data 10 times per second in one of our usual applications.  Though in a vibration measurement application I would like to get up into high-speed logging of the data.

[DianeS]

At 10S/s, it's unlikely that you would run into any kind of problem with displaying your front panel indicators from your DAQ loop. 

Define "high speed". 

I hope the example helped to illustrate some of the concepts I've been pushing!  If you have questions on it, post back with them.

[jonathanupr]

5000S/s for vibration analysis...

I figured I could look to run a sub-panel as though not to cause overhead with the more user oriented interface front panel that I have right now.

[DianeS]

Are you using a graph or a numeric indicator to display your data?

You probably only need to update your front panel every 200-500msec or so.  I usually update at a 500msec rate when I'm displaying collected data.  It's easy for the human eye to look at, and fast enough that the user doesn't feel like the app is running slowly. 

As I said in an earlier post, there are lots of good ways to display your data, and we can discuss those once you are comfortable with queues and how they work, and how to use them in your app.  I would also direct you to another discussion on this forum in which folks are talking about ways to stop multiple loops, found here.

Anyway, a sub-panel would also work for displaying your data if you're comfortable doing it that way -- it just seems like an unnecessarily complex way to do it.  You can queue data between VIs, though, that's one of the nice things about queues!  So you could queue the data into your sub-VI and choose to display the front panel when opened, or something similar.