LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQ Assistant vs. Producer-Consumer architecture


@HorseBattery_Stapleguy wrote:

@mcduff wrote:

Producer Consumer should never be used for DAQmx acquisition unless you have specific needs. DAQmx has built in TDMS logging that is highly efficient and easy to implement into code. If you need a different file format, post-process the data, use the free Excel plugin for TDMS, etc.

 

mcduff


But this is only when you're logging right? Wouldn't you need to use a similar architecture if you wanted to display data to the user in "real time" ?

 

In my case some people didn't want to switch to RT or PLCs, so they wanted all control and acquisition to be done through DAQmx. Of course, its not like that was ideal...


No. It works for logging only, logging and displaying, and display only. See the message right above your message. See how there are multiple logging modes, including "off".

 

mcduff

0 Kudos
Message 11 of 16
(212 Views)

@mcduff wrote:


Once you set up TDMS logging, it is not an always save operation. A simple DAQmx property node is all you need. The case statement below is what I use in my programs when the user hits the save button.  (I also give the option of log only, that is, save without seeing the data. This mode is the most efficient.)


I hate to derail the thread but this is interesting. Is your user hitting the Save button before a run or after? I always assumed logging happened when the data was taken and thus a file was always created if logging was enabled.

0 Kudos
Message 12 of 16
(206 Views)

@BertMcMahan wrote:

@mcduff wrote:


Once you set up TDMS logging, it is not an always save operation. A simple DAQmx property node is all you need. The case statement below is what I use in my programs when the user hits the save button.  (I also give the option of log only, that is, save without seeing the data. This mode is the most efficient.)


I hate to derail the thread but this is interesting. Is your user hitting the Save button before a run or after? I always assumed logging happened when the data was taken and thus a file was always created if logging was enabled.


I think "during" is a better description. (Note everything is manual, no triggering etc.)

 

Note: We do continuous recordings, like a "tape recorder". Not sure of your age, but think of a tape recorder wired into your radio. The song you like comes on, hit record, for the next song hit pause, etc. (You may or may not get that analogy.)

 

Depending on how you set up your task and your preferences, you may not have to stop the task at all. I do, because I want to the filename to change, otherwise the first iteration will use the old filename. Note that log only implies some special conditions, like the number of points need to be an integer of the file sector size etc. You can even change the filename on the fly, if wanted. The logging feature in DAQmx is really well thought out and under appreciated.

 

So my program works as the following, unless specified by the user a "view only" mode is shown by the DAQ, no save, then they can click to save if they are satisfied with their settings. That means when the task is set up, the log mode is set to off.

 

mcduff

 

 

Message 13 of 16
(202 Views)

@mcduff wrote:


I think "during" is a better description. (Note everything is manual, no triggering etc.)

 

Note: We do continuous recordings, like a "tape recorder". Not sure of your age, but think of a tape recorder wired into your radio. The song you like comes on, hit record, for the next song hit pause, etc. (You may or may not get that analogy.)

 

Depending on how you set up your task and your preferences, you may not have to stop the task at all. I do, because I want to the filename to change, otherwise the first iteration will use the old filename. Note that log only implies some special conditions, like the number of points need to be an integer of the file sector size etc. You can even change the filename on the fly, if wanted. The logging feature in DAQmx is really well thought out and under appreciated.

 

So my program works as the following, unless specified by the user a "view only" mode is shown by the DAQ, no save, then they can click to save if they are satisfied with their settings. That means when the task is set up, the log mode is set to off.

 

mcduff

 

 


Ah, I see. Thanks- I can see how that'd work. I wasn't actually aware you could toggle the TDMS logging while a task was running.

 

Our tests are basically always "run when the user clicks a button, then review processed data". Logging wouldn't be super helpful there as I'd have to delete/modify old files manually. Thanks for the tips though, kudos.

0 Kudos
Message 14 of 16
(196 Views)

This ended up being interesting to me too!

 

I'll admit, mcduff, that I had to look up what "refactoring" code means. haha! I guess I'm living a blessed/cursed (depending how you look at it) existence in my own difficult-to-decipher code bubble over here.

 

 

The DAQmx property nodes configuring mode 1) logging only, 2) logging and displaying, and 3) display only --- this looks very clean and useful.

 

Would you select mode #1 if display charts bog down the application -- perhaps a problem for a high-speed event?

And use mode #3 to confirm instrument measurements are as expected, without generating a ton of unwanted data files? 

 

I fished around the example finder for something like this but just found " TDMS Write Events Data.vi ". It is more a generic example doing mode #2 and no logging options as you showed in the snippet above.

 

Am I out of place asking for one of your codes that does this? Or could you point me to a better example vi ? I see the property node goes in T/F case structure, but when you select mode #1) logging only does the task bypass the display stuff somehow?

 

Thanks---

Jeff

 

P.S. I'm interested in the efficiency differences between these modes, as this morning I got assigned to figuring out a data acquisition for accelerometers recording a simulated earthquake motion. Needless to say there are some high speed effects we need to capture.

 

 

0 Kudos
Message 15 of 16
(137 Views)

@JThorus wrote:

This ended up being interesting to me too!

 

I'll admit, mcduff, that I had to look up what "refactoring" code means. haha! I guess I'm living a blessed/cursed (depending how you look at it) existence in my own difficult-to-decipher code bubble over here.

 

 

The DAQmx property nodes configuring mode 1) logging only, 2) logging and displaying, and 3) display only --- this looks very clean and useful.

 

Would you select mode #1 if display charts bog down the application -- perhaps a problem for a high-speed event?

And use mode #3 to confirm instrument measurements are as expected, without generating a ton of unwanted data files? 

 

I fished around the example finder for something like this but just found " TDMS Write Events Data.vi ". It is more a generic example doing mode #2 and no logging options as you showed in the snippet above.

 

Am I out of place asking for one of your codes that does this? Or could you point me to a better example vi ? I see the property node goes in T/F case structure, but when you select mode #1) logging only does the task bypass the display stuff somehow?

 

Thanks---

Jeff

 

 


Honestly, I am not sure what exactly you are doing, except that you are working with nuclear containment.

  1. Your block diagram is too big, you need to break it down into smaller parts, such that it fits on a normal screen.
  2. A lot of your code seems repeated, you could break it down into For Loops.
  3. UI interactions seem all over the place, I would put them in a single place, an event loop and send messages to other loops as to how to respond.
  4. It looks like you are saving processed data here, maybe the mean of the data, not sure I can't see your subVIs. For this case DAQmx logging is not applicable; it saves all of the data.
  5. Use the built in Example Finder. Lots of good stuff there.

I modified one of the examples, to get the Mean from 8 channels of a 6211 sampling at 10kSa/s and receiving 10k samples. Normally you don't do processing in the event loop. However, in this case we know each event occurs once a second, and taking the average of data once a second should not be a problem.

 

The VI is attached is 99% example finder, look in there for good ideas.

 

You will need to change the device and channels in the attached VI.

 

mcduff

Message 16 of 16
(124 Views)