Error on Wait for Next Sample Clock

[fdavid]

Hello,

 

I need to measure the speed using an encoder for a control application. I have setup an external sample clock on CNTR0 (in a different vi) and I have wired CTR0_OUT to CTR1_GATE. I'm starting the sample clock vi, then the speed measurement vi and Labview shows the next error. I don't know what's going on, my measurement is set for Sample Clock and timing with hardware-timed single point sample type and the error says that I'm not doing that??? What's funny is that the same application works if I'm using the DAQ Assistant.

 

Thanks,

David

[Kyle_A.]

Hi David,

A few clarifying questions that would help out here is what hardware are you using and are you using DAQmx Base or DAQmx to program?  What versions of DAQmx and DAQmx Base do you have?  What operating system are you using?

Here is an article with supported devices on Hardware-Timed Single Point.  Review your hardware to see if it is in the compatible list of devices for this operating mode.

If you are generating an external clock and using it for your sample clock, for what reason do you need the mode to be Hardware-Timed Single Point?

[Kyle_A.]

Sorry, here is that article I was referring to:  Does My DAQ Device Support Hardware-Timed Single Point Sampling Mode?

[fdavid]

Hi Kyle,

Thanks for your reply. Here is what I’m using:

- PCI-6221 with SC-2075 I/O board

- DAQmx 8.9

- Windows XP Professional

After reading your message I have noticed the mxBase Wait for Next Sample Clock and replaced it with the DAQmx version and now it’s working. Is this OK? According to the document you have referred me to, it shouldn’t (only analog inputs and outputs are supported by M series).

I’m using Hardware-Timed Single Point because I’m developing a control application and I get unacceptable delays with buffered acquisition. The problem now is that I can’t go over 200Hz sampling rate (Wait for Next Sample is missing sample clocks) and I need at least 1kHz. Is this a limitation of the board I’m using, is there a way to increase the sampling rate?

Thanks,

David

[Kyle_A. · Accepted solution]

Hey David,

I believe that document I have linked may be wrong, and I will go ahead and make the necessary changes to correct that document on my side.

The next issue that I can see is using HWTSP on a windows machine. HWTSP is typically reserved for computers that are running real-time operating systems. These operating systems can ensure deterministic operations. On windows XP, windows might decide to handle another thread / process which may cause you to miss a sample (if you miss a sample the default behavior is to throw an error).

With HWTSP, you will be hard pressed to get a faster sampling speed without a real-time system.  Buffered acquisition will also have a high amount of latency for a control application.

Looking at your code, I would recommend trying to do a CI Frequency On Demand sampling task.  Currently, your code is taking the edges and converting to frequency/RPM.  In addition, due to phase misalignment with your sample clock, your current setup introduces a ±1 count error.  This translates to ±1KHz error (for 9 counts in 1ms it would be 9KHz, for 10 it would be 10KHz, etc.).  Based on the math in your example, you are introducing ±120 RPM of error.  By doing a frequency on demand task, you can ensure that every time you call the DAQmx Read, you are getting the latest frequency within a ±1 tick of the timebase error.  This not only gives you better accuracy, but as long as you keep the loop rate fast, you will ensure you are getting the latest frequency at the fastest rate possible. 

One way to ensure that your loop rate stays fast is to remove the processing from your acquisition loop and placing it in a parallel while loop.  This can be done by the use of notifiers.  Loop rates in Windows are generally in the milliseconds.  To achieve faster loop rates, you might want to consider a real-time operating system.

Please let me know what you think of this, and if you have any more questions, I can go into this into more detail.

[fdavid]

Hi Kyle,

It looks like we can't use our current setup in the way we were thinking. We're developing a control systems lab and we can still do a buffered acquisition for offline system identification (the first part of the lab), but not for the control portion itself. The motor we're using in the lab has a settling time of about 100 msec and we need at least a couple hundred control points in that interval.

Thanks,

David