From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Continuous data acquisition and analysis in real time

Solved!
Go to solution

ECG Block Diagram.png

 

 

Hi all,

 

This is a VI for the continous acquisition of an ECG signal. As far as I understand the DAQmx Analog read VI needs to be placed inside a while loop so it can acquire the data continously, I need to perform filtering and analysis of the waveform in real time. The way I set up the block diagram means that the data stays int the while loop, and as far as I know the data will be transfered out through the data tunnels once the loop finishes executing, clearly this is not real time data processing. 

 

The only way I can think of fixing this problem is by placing another while loop that covers the filtering the stage VIs and using some sort of shift registeing to pass the data to the second loop. My questions is whether or not this would introduce some sort of delay, and wether or not this would be considered to be real time processing. Would it be better to place all the VIs (aquicition and filtering) inside one while loop? or is this bad programming practice. Other functions that I need to perform is to save the data i na file but only when the user wants to do so. 

 

Any advice would be appriciated. 

 

 

0 Kudos
Message 1 of 3
(6,566 Views)
Solution
Accepted by jquinno

You have two options:

 

  • A.  As you mentioned, you can place code inside your current while loop to do the processing.  If you are clever, you won't need to place another while loop inside your existing one (nested loops).  But that totally depends on the type of processing you are doing.

 

  • B.  Create a second parallel loop to do the processing.  This would decouple the processes to ensure that the processing does not hinder your acquisition.  See here for more info.

 

Your choice really depends on the processing that you plan to perform.  If it is processor-intensive, it might introduce delays as you mentioned.  

 

I would reccomend you first try to place everything in the first loop, and see if your DAQ buffer overflows (you can monitor the buffer backlog while its running).  If so, then you should decouple the processes into separate loops.

 

Regarding whether or not "this would be considered to be real time processing" is a loaded question.  Most people on these forums will say that your system will NEVER be real-time because you are using a desktop PC to perform the processing (note:  I am assuming this is code running on a laptop or desktop?).  It is not a deterministic system and your data is already "old" by the time it exits your DAQ buffer.  But the answer to your question really depends on how you define "real-time processing".  Many lay-people will define it as the processing of "live data" ... but what is "live data"?

 

http://www.medicollector.com
Message 2 of 3
(6,510 Views)

The first step I would take is to put your processing in the same "While Loop" as the DAQmx Read.  That loop is currently mostly idle (waiting for data from the DAQmx buffer) and could do the processing instead of just waiting.  It will keep your code simpler than passing the data to another loop.  Saving the data could also fit in this loop, probably insie a "Case Structure" that it can be enabled or disbabled by the user.

 

Message 3 of 3
(6,503 Views)