State Machine + DAQmx slow acquisition

[Simon-lee]

Hi Folks,

I'm after some advice.

I have an application to test a wheelchair hoist actuator. While the state machine functions perfectly (thanks to mcduff and others from a previous post). I'm a little disappointed that I'm only collecting 27 points over the actuation time (unloaded this is about 4 seconds but might be as high a 6.9 secs loaded), 

I believe the DAQ is running in "on demand" mode which might be wrong. I have tried "continuous" but I struggled with buffer problems and finite doesn't look right.

If someone can have a look at the project and give me some ideas where to look for the bottleneck.

Note: The third party timer is  

Timer v2.0.0.9 by NI
Released On: Fri, 15 Jun 2018 16:03:22 
Author: Piotr Kruczkowski

Project saved in Labview 17 zip

Thanks 🙂

[McQuillan · Accepted solution]

I had a quick look at your code, and yes, your DAQ is set to on-demand, which basically means it will request a sample whenever the DAQmxRead VI is called.

Two things pop to mind:

1. If you're after a higher sample rate, then you could use the DAQmx Timing VI where you can set your acquisition to hardware timed continuous sampling (hardware dependent)
2. If step 1 is what you're after, then I would also recommend creating a second acquisition loop that can continuously acquire the data. You can then pass the data to the first loop using a queue. - As seen in the Producer-Consumer design pattern.

However, (this might be a bit of a jump from using a state machine) I would recommend checking out the Continuous Measurement and Datalogging sample project. This could be an ideal design pattern for you to use (QMH). From the LabVIEW Welcome Screen>Create Project>Sample Projects>Continious Measurement and Logging.

[Simon-lee]

Hi McQuillan,

Thanks for the reply, I have played with continuous sampling within the state machine but I ran into buffer overflow issues.  I agree that a second loop would solve the issue but I feel notifiers make sense as I’m only interested in 4.5 seconds with 30 seconds dwell time and I don’t want to run out of buffer in the Que. Also I can't help feeling there is a more elegant solution.

However you have given me an idea, continuous acquisition within the state machine can work if I can purge the buffer between states. From my limited knowledge the buffer is only released when the task is cleared. Is there another method?

I guess the brutish solution would be to clear the task after each acquisition state and re-initialise it before the next one. Again this doesn’t feel a right.

Any feelings on that suggestion.

Thanks and regards

Si

[Kevin_Price]

There's a method I used to use a lot (and still would for the right kind of app) that works really well for this kind of situation.  You can set up a continuous acquisition, specifically program a DAQmx property node to allow buffer overwrites, and then whenever the moments arrive that you *care* about the data, you can query to get the most recent N samples.  It's nice because they're already there waiting, and you can set the task to sample at a much higher rate than you could achieve with on-demand reads.  You also get more options to to do some filtering, averaging, or even just the ability to look into the recent past and retrieve pre-trigger data.

Here's a post I made about it with a snippet and more explanation.

-Kevin P

[Simon-lee]

Hi Kevin,

Thanks for the response, I’ve not had much chance to have a play  but it looks really promising - Unfortunately the unit has go off for environmental tests so I won’t get back onto real hardware for a week or so.

As soon as its back I shall post an update,

Thanks again

Si    

[mcduff]

Kevin's solution looks promising, I would try that first to see if it works.

mcduff

[Simon-lee]

Hi Folks,

I finally have my hardware back so I’m in a position to play.

As I’m under time pressure so I’m going to start with McQuillan's approach. However, this does lead me to another question.  If I break out the acquisition into a separate faster loop (I’ll try lossy notifies to avoid buffer problems).

This means I will have tasks running at different speeds (and modes). Now, I once tried this with a usb6009 DAQ and it didn’t end well.   

I’m confident that the suggestion will work, so I assume there is something in a professional DAQ that is missing in the USB and the differences revolve around time.

So, the question is “are there limitations and caveats to the number, speed and modes I can use with a single chassis” I appreciate that individual modules have speed limits dependent upon inputs but I feel things are far more complex than that.

Thanks

Si

[McQuillan]

Hi Si,

The USB-6009 doesn't have a hardware clock, so has to be software timed. Your data rate is quite low (<100S/s - if I remember correctly) so you could use a lossless queue if you want to analyse all the data without missing any. You can always use 'Get Queue Status.vi' to monitor your queue buffer to ensure it's not going crazy - but from what I've seen, it shouldn't.

---

So, the question is “are there limitations and caveats to the number, speed and modes I can use with a single chassis” I appreciate that individual modules have speed limits dependent upon inputs but I feel things are far more complex than that.

---

Could you give more detail about the hardware configuration you were thinking of? In my experience, it's not that more complex 😉

[Yamaeda]

---

@McQuillan wrote:

Hi Si,

The USB-6009 doesn't have a hardware clock, so has to be software timed. Your data rate is quite low (<100S/s - if I remember correctly) so you could use a lossless queue if you want to analyse all the data without missing any. You can always use 'Get Queue Status.vi' to monitor your queue buffer to ensure it's not going crazy - but from what I've seen, it shouldn't.

---

http://www.ni.com/pdf/manuals/375296c.pdf

It has a 24MHz internal clock for AI, but maybe you're referring to some other clock?

With such low speeds, 100S/s, i'd set sample rate to 1 kHz and read and average 10 samples at a time.

/Y

[McQuillan]

Update: I haven't looked at the spec for the 6009 - I was pretty sure that device couldn't be hardware timed, by maybe I'm wrong.

Second update: Yep, you're right! The 6009 does support HW timed AI

Yep - Totally agree.

 I'm pretty sure you could change the CML sample project UI and have most of your application done (you might need to remove some of the HW timing functions in DAQmx if they're not supported)