change from finite to continuous mode

[Jun_l]

So since I messed up my first question, here's a second try:

I have a programm that runs at finite sample mode, but will not when I use continuous mode. From what I know, the difference between the two modes are how they acquire the data samples - the continuous mode continues to run even after samples are required, and with finite samples only the number of samples given by me is going to be logged.

My programm (see VI attached) is written with finite samples to log voltage and current, my voltage and current signals are however very laggy, which I think might have something to do with the finite sample mode. I want to find a way to avoid such lagginess, since this could influence my results (phase angle between voltage and current). Right now I am using 100kHz sample rate with 100kHz # of samples.

I would like to compare the data with those from in continuous mode, since the frequency of my signals will range from 50 Hz to 2kHz, I would like to set a sample rate of 2MSa and an acquisition period of 1s.

How can I do that? Would it help if I put my daqmx read vi in another for loop? Could this be a better alternative?

Would love some insight or opinions!

Jun

[crossrulz]

Your problem is that you are not constantly getting data.  The biggest advice I can give you here is that if you are using a Queued Message Handler, the QMH should (almost) never enqueue onto itself.  You are just asking for some really weird race conditions.

In this case I would add a shift register for the queue timeout.  Have it default to -1 (wait forever).  When you get the message from the UI to start reading the data, you start the task and set the queue timeout to 0.  Now when the queue times out, you read the data.  Do not stop the task until you get the command to stop.

I would also go so far as to move your file logging and data processing into other loops.  You can use a similar structure that you already have here (QMH).

[Kevin_Price]

Additionally, your call to DAQmx Read doesn't specify the # samples to read.  When left unwired, the default value is -1.   This default value carries a special meaning and that meaning is *VERY DIFFERENT* between continuous sampling and finite sampling tasks.

In a finite sampling task it means "wait to accumulate the entire buffer full of samples then return them to me all at once."  In a continuous sampling task it means "whatever # of samples are available *right now*, even if that # is 0, return them to me without waiting.

In your code, you start the task right before this call to DAQmx Read and then stop the task immediately after it.  In finite sampling mode, that works fine.  In continuous sampling mode, you end up reading only a very few samples (possibly 0), and then stop the task.

I keep seeing how this difference in behavior causes confusion in a number of threads over the years.  I recently posted about it in the Data Acq idea exchange, give the idea a Kudo if you like it.

-Kevin P

[Jun_l]

Hello crossrulz,

thanks for the response, im trying to understand what you said:

1)

---

@crossrulz wrote:

Your problem is that you are not constantly getting data.  The biggest advice I can give you here is that if you are using a Queued Message Handler, the QMH should (almost) never enqueue onto itself.  You are just asking for some really weird race conditions.

---

QMH should not enqueue to itself, are u saying that I should remove the queue output from my dequeue element that enters my enqueue element? Or what do you mean? For example in the picture below, after Get Data the next case that should be run is CondSignal. I don't see how it could run otherwise?

Second, I hope I understood what you mean with the shift register and -1 as default:

But I don't quite get what you mean in the next sentence:

---

@crossrulz wrote:

In this case I would add a shift register for the queue timeout.  Have it default to -1 (wait forever).  When you get the message from the UI to start reading the data, you start the task and set the queue timeout to 0.  Now when the queue times out, you read the data.  Do not stop the task until you get the command to stop.

---

Could you please elaborate? Because wiring -1 to it doesnt seem to change anything (i'm pretty sure Im missing something)

Jun

---