LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Live view data with periodic sampling and analysis, daqmx

Hello All, 

I have an idea for a project and I just can't get started.

Using a cDAQ Chassis (9174) and a 9215 card I would like to live display a collection of 6 Analog Inputs on a waveform graph. 
A secondary loop would then be running every 20 minutes to log a sample of the data, 10 seconds worth for example, save it to a TDMS file and then repeat continuously until the experiment is complete.

Ideally in the future I would like to build a secondary display which takes an average of the logged data and plots it over time, measuring some slow voltage degedration of an electrochemical cell over a number of weeks. We will also aim to expand the number of channels and cards with various signal types for different sensors. 

I did as I always do when starting a new project, and browsed through the boards for a previous example, but could not find the right keywords, if anyone has any example codes for a similiar project it would be greatly appreciated. 

regards,
Jordan

0 Kudos
Message 1 of 7
(1,120 Views)

You start by setting up a continuous acquisition that sends the waveforms to a chart.

Also send the waveforms to another loop through a queue.

 

If conditions are met, such as an elapsed time timer running in the second loop, so 20 minutes have passed, send the next 10 seconds of data it receives to the TDMS file, otherwise do nothing with the data.

0 Kudos
Message 2 of 7
(1,109 Views)

Just as a small variation, I've found this kind of situation to be a good use case for a lossy queue.  You make a fixed-size queue that can hold 10 seconds worth of data and then keep writing your new data to it using "Lossy Enqueue Element" in the Queue palette.

 

At any given instant, you've got the *previous* 10 seconds of data stored.  This is useful in a lot of applications where you don't know when some event might occur, but when it does you want a close look at the recent-past data leading up to the event.

 

It sounds like you're on a regular logging schedule where you could do things either way, but I think you'll find more *future* uses for a scheme like a lossy enqueue that gives you visibility into the past.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 7
(1,077 Views)

Thankyou RavensFan and Kevin for the advice, your suggestions lead me down an alternative path, which is more within my capabillites.

I firstly created a simple DAQmx subvi which reads the data and outputs to a waveform 
I then used hte Master/slave template to seperate out the loops 
using the elapsed time function I can control how long the master (constant reading of the daqmx tasks) will run until it tells the slave (save a section of data) to execute 

It's not overly pretty, but it's a start. 

 

my biggest gripe is that by doing it in this way, I obviously miss the section of data from the live display when it is running the slave loop, 
no big issue for this implementation, but if I resuse the code in future for another project it may be a nuisance.


Jordan29_0-1599609353881.png

 



0 Kudos
Message 4 of 7
(1,053 Views)

Instead of a string for your Notifier, you could set the Notifier datatype to be a waveform (or an array of waveforms if that's what you're getting, I can't tell from the pic.)

 

Then just branch your waveform(s) wire into the case structure and send it as a Notification when Elapsed Time says to.  So the logging loop gets its own copy of the data instead of stealing it from the display loop.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 7
(1,046 Views)

Thankyou for the tip! I did that and am now streaming the waveform directly through the notifier 

cheers, Jordan

0 Kudos
Message 6 of 7
(1,032 Views)

With further thought, here's another tip to consider:

 

Notifiers can be lossy.  There's no certainty that the consumer will receive each one that's sent by the producer and it's also possible for the consumer to retrieve the same data twice (or more).

 

Two better options arise from this, the first is what I'd recommend:

1. Send data to the logging loop via Queue rather than via Notifier.  It'll be simple 1-for-1 replacement of the functions.   Send turns into Enqueue, Wait on Notification becomes Dequeue. 

2. Restructure the code so that the live display (which isn't mission-critical) is the part that receives data via Notifier.  

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 7
(1,020 Views)