Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Error on Wait for Next Sample Clock

Solved!
Go to solution

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

 

 

Error.JPG

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Block Diagram.JPG

0 Kudos
Message 1 of 6
(7,255 Views)

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.
National Instruments
Senior Applications Engineer
0 Kudos
Message 2 of 6
(7,228 Views)
Sorry, here is that article I was referring to:  Does My DAQ Device Support Hardware-Timed Single Point Sampling Mode?
Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 3 of 6
(7,226 Views)

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

0 Kudos
Message 4 of 6
(7,218 Views)
Solution
Accepted by topic author fdavid

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.

Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 5 of 6
(7,192 Views)

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

0 Kudos
Message 6 of 6
(7,139 Views)