Sampling Rate problem

[PeterBrown]

I thought I had my vi programmed correctly using a virtual device instead (as I don't have the hardware with me at the moment) but it seems the sample rate is not changing to 5Hz as expected.

I thought the problem with simulated devices sampling rates was fine these days.

Any task should work so I haven't uploaded my simulated task, however can upload that if it helps.

The second while loop is the one I am interested in.

Does anyone see any reason why the sample rate is not changing to 5Hz as wired up the timing vi?

[cbutcher]

A few starting thoughts:

• You set the rate to 5 twice. Does it not give 5Hz sampling in either case, or only the second is a problem?
• You don't check the error wires from your DAQmx calls. Try connecting these up and probing/adding indicators to see if there's some error (it might not be possible, depending on device etc)
• You have a Wait (ms) and the DAQmx Read in your second loop - the Wait won't do anything probably (because you want 5 samples at 5Hz, so it should always take ~1s for the loop). Remove the Wait to avoid overconstraining (although here, there's no effect).
• You're setting a bunch of property nodes every iteration with constant values - you can do this before your loop and then avoid having to do it over and over again. Use error wires to sequence, or add a Flat Sequence Structure if you must 😉

[Henrik_Volkers · Accepted solution]

Without looking at your code...

Most DAQ devices support only a limited set of samplerates.

Often you have a clock source running at some x MHz and a clock divider n (again range limited) , giving you the x/n rates.

PLL clock sources add another multipier m so x*m/n are possible rates , finally a DDS clock source with nearly arbitary rates ...

The manual and specification of your DAQ will answer the question of what samplerates are actually possible.

A lot of DAQ devices have a lower samplerate not covering 5 Hz. In that case you simply sample at a hioher rate (1kSPS) and do a software decimation.

It's a good idea to read the actual samplerate property (or check the dt value in the wfrm) after configuration, since the driver will coerce to the next higher SR.

[PeterBrown]

Thanks for your suggestions.

I set the rate twice because the first rate didn't seem to change it. May remove it now.

I now moved the property nodes into a for loop that runs between the two while loops now.

With the daqmx errors wired up I get the error below but it only occurs after acquiring for a while. I was wondering if this was related to the acquisition on the simulated device going flat out rather than the rate setting being ignored.

Hopefully the real hardware doesn't show this behavior. I may check with some different hardware tomorrow to check.

[PeterBrown]

Seems the simulated device (perhaps the hardware version as well) sample rates of 2kHz, 4kHz etc are fine.

So yes that seems to be the problem as  Henrik_Volkers comment suggests.

I will play with the real hardware in a few days so will move onto changing/developing other parts of the code.

Thanks to both of you.

[PeterBrown]

One question. Are the sample rates defined by the modules themselves in a Compact DAQ chassis I assume? Rather than the chassis.

Reason I ask is that I hope there is a common scan rate for all modules as there will be 3 types of modules in the chassis.

[Yamaeda]

With such low rates it's either SW timed for single samples or as mentioned the lowest HW timing and downsample.

Which is more fitting is dependant on your requirements.

/Y

[cbutcher]

---

@PeterBrown wrote:

One question. Are the sample rates defined by the modules themselves in a Compact DAQ chassis I assume? Rather than the chassis.

Reason I ask is that I hope there is a common scan rate for all modules as there will be 3 types of modules in the chassis.

---

If you tell us which modules we could probably give a concrete answer.

With DAQmx, a task can (AFAIK) only have a single sample rate, but you could depending on hardware put different channels/devices in different tasks.

It sounds more like you want the opposite, in which case you can either put multiple devices in one task, or use a shared source when configuring timing.