DAQmx Sample clock doesn't appear to be working

[coolhandLV7]

See the attached vi.  i set the sample rate for the DAQmx sample clock vi but the loop time just runs at 80ms no matter what i set the sample clock to.  The data that is being saved reflects the 80ms capture rate.  I don't understand why the loop is cruising along when the DAQmx Read should only be firing at the sample rate set by the Sample Clock.vi...

Any help would be appreciated.

[Norbert_B]

Wow

this is how NOT to implement continuous acquisition. You are hogging the CPU by colelcting single values each iteration and stopping the task. Why are you doing this?

Please refer to DAQmx examples for proper continuous acquisition coding.

[BertMcMahan]

The sample clock starts running when you start the task. Your first sample will be a little less than 80 ms, since you manually start the task, but since you stop the task you also stop the sample clock. The next call to Read will restart the sample clock, meaning there's never a delay.

Please look up the examples for continuous acquisition. You will only need to start and stop your task one time each- you start the task when you begin acquiring, and stop it when the acquisition is done.

If you remove your Stop Task, it should work (though I don't have all of the dependencies to run your code so I can't tell for sure). Still that's a bit of an odd way to do continuous acquisition. The sample clock will then control your timing, and you should make sure there's nothing in there that runs SLOWER than your sample clock rate, otherwise the buffer will overflow.

[Norbert_B]

---

@BertMcMahan wrote:
[...]If you remove your Stop Task, it should work (though I don't have all of the dependencies to run your code so I can't tell for sure). Still that's a bit of an odd way to do continuous acquisition. The sample clock will then control your timing, and you should make sure there's nothing in there that runs SLOWER than your sample clock rate, otherwise the buffer will overflow.

---

Since the VI contains code to retrieve only single values from the buffer, the buffer will overflow very quickly (depending on clock setting of course). Additionally, the logfile includes timing information which is created software-wise per sample, so it will not significantly improve. The decrease which could be seen by removing stop task is the buffer access vs. hardware interaction. I doubt that this decrease is anywhere near to what the OP expects.

[coolhandLV7]

Thanks Bert McMahan.

Yup made a mistake and included the Stop and Clear DAQmx vi's in the loop.  I moved them outside of the loop and created a case to stop and clear the DAQmx resource to allow a change in sample rate to be detected and applied.  

[BertMcMahan]

---

@Norbert_B wrote:

---

@BertMcMahan wrote:
[...]If you remove your Stop Task, it should work (though I don't have all of the dependencies to run your code so I can't tell for sure). Still that's a bit of an odd way to do continuous acquisition. The sample clock will then control your timing, and you should make sure there's nothing in there that runs SLOWER than your sample clock rate, otherwise the buffer will overflow.

---

Since the VI contains code to retrieve only single values from the buffer, the buffer will overflow very quickly (depending on clock setting of course). Additionally, the logfile includes timing information which is created software-wise per sample, so it will not significantly improve. The decrease which could be seen by removing stop task is the buffer access vs. hardware interaction. I doubt that this decrease is anywhere near to what the OP expects.

---

Definitely, that's what I meant by the things running slower than his acquisition. I don't know what the overhead is for each Read call (as long as it's not starting the task), but if he was only sampling at around 100 Hz it would probably work. His default value is 1000 Hz which is probably too high, but it's not THAT far outside a reasonable number. We know from his data already that, along with starting and stopping the task, that he can hit at least 12.5 Hz 🙂 Writing to disk each loop will also be pretty slow, but getting rid of the disk write and start/stop task would significantly increase his execution speed, and he MAAAAY be able to get to 1000 Hz.

Doing it the right way would be a lot easier though 🙂