Counting motor ramp up with DAQmx with 10us resolution

[Stefanich]

Hi

I need to measure a motor ramp up and down precisely. In traditional NI-DAQ I did by "Count Events of Time.vi" from the 1EASYIO.LLB.

It reports the time since start, so I know when the encoder slopes occured. I need to measure approx. 5 seconds with a few hundred time ticks.

Unfortunately my new USB-hardware DAQPad-6016 does not support this vi.

Is there a MX replacement ?

Since I want to stay with the USB-bus I could buy use a DAQPad-6020E, but I dislike to invest again.

Rgds

Eric Stefanich

[Carsten_Sprung]

Hi Eric,

according to the new philosophy behind NI-DAQmx there is no direct replacement for the trad. DAQ-VIs. Under the following link you can find a comparison between NI-DAQmx- and trad. DAQ-Counter VIs

http://digital.ni.com/public.nsf/websearch/F4EFF28CBDC744EF86256E93007E660E?OpenDocument

The next link gives an overview what terminoloy changes have been made in between DAQmx and trad. DAQ

http://digital.ni.com/public.nsf/websearch/7759B0D2A8A392DF86256D21001B452E?OpenDocument

As you may know the strategy in DAQmx is to use the same VIs for all kind of acquisition and the configure them the way they are needed. Please have a look to the NI example finder in LabVIEW. There are a lots of examples how to implement event counting in DAQmx. You can find some example code in the Developer Zone as well.

Best regards,

Carsten Sprung
Applications Engineer
National Instruments Germany

[Stefanich]

Hi Carsten

thanks for the links.

In the meantime I similar DAQmx-functions for the traditional NI-DAQ functions I used before. It was difficult to find because it is named "event counter". This is misleading because it does not count the number of events itself as the name says. It results in timestamps WHEN the events occured. 

After some coding with DAQmx I reached the roads dead end, because the DAQmx counter drivers are not complete. They all lack DMA mode for continous mode. The interrupt driven drivers get errors -200141 all the time.

I checked DAQmx Base 2.0 which introduces DMA support, but it does not support any of my counter cards.

Now I am going back to traditional NI-DAQ for buffered operation and hope the included DMA will be fast enough.

I was not aware that all counters have counter FIFOs for only ONE sample and the buffered samples must be written to system memory. So my decision for USB DAQpad-6016 was wrong. I switch to a PC-6711E to be faster.

I also learned that I cannot use traditional and DAQmx at the same time for one card. This is also a drawback..

A first disappointing conclusion is, that DAQmx is NOT a full replacement for traditional drivers, because it does not DMA.

Rgds

Eric

[Kevin_Price]

Eric,

I have very little experience with the USB devices and don't really know whether your 6016 will be capable of the task you want to do.   You mentioned needing a few hundred samples in about 5 seconds which "feels like" it should be do-able, provided the rest of the app doesn't bog down the CPU.  As you've discovered, the on-board FIFO for counters is very small , so your CPU will have more work to do in such a data acq task.  

In any case I'm almost certain that any shortcomings are NOT due specifically to the DAQmx driver as compared to traditional NI-DAQ.  The lack of DMA support is not particular to DAQmx -- it's the 6016 device itself that doesn't support DMA.

You mentioned considering the purchase of a USB 6020E.  Check this with your local NI sales/tech rep, but I am >90% confident that you'd be better off considering a USB 6251.  It's cheaper, has better specs, and *appears* to have a much-enhanced ability to stream continuous data.  Here's the product page.

Meanwhile, can you describe in more detail what your app needs to do?  Can you post the code you've tried?  I think there's a good chance of improving the performance of your app, if your baseline comparison is an old "EASYIO" example.  Hopefully someone that's used a 6016 for a continuous counter task can join the thread.

-Kevin P.

[gus]

I am 100% confident that the USB-6251 is a better USB solution than the USB-6020.

You might not want to use USB at all though.  What are the data rates that you are attempting to stream?  PCI is going to provide better throughput rates for counters than USB devices.  Actually, it may be more important to just get a general idea of what you are working to accomplish.

[Stefanich]

Hi Kevin and Gus

Thanks for advise.

I made reasonable progress and am near to what I need.

To clarify my application: I have a motor ramp-up coast-down cycle. Measure the accurate time when edges of a the digital tacho occur with high resolution (better than 10 us) without missing any pulse. I need to count up to 400 Hz and need up to 2000 pulse.

Status

- I switched to a PCI-6711 counter and did some traditional buffer programming. I ended in a lot of error messages (like timing limitations, setting error without saying where it is and so on).

- I updated my DAQmx-8.0 to 8.1: This was a big success: Previously I had -200141 almost every time after 3-20 pulses. I can now count a few hundred pulses (on a PIII 750MHz machine). I get rare -200141 on approx. every 20th ramp up. The readme file of the DAQmx does not say that data transfer was improved, but obviously it is.

To get rid of all -200141 I need more improvements.

Questions:

1. Does DAQmx really support counter DMA ? I thought I need DAQmx base 2.0 for this ?

2. How can I make sure that DMA is used and not IRQs ? Is it enough to declare continous sampling when defining the task in the MIE (Measurement and Instrumentation Explorer)

3. Can I ask LabView if this task uses DMA ? To make sure I set DMA with the channel proerty node, but got -200371 (cannot define another channel on same device). I assume this is because I declared the task in the MIE already.

4. Does it make sense to set the buffer size ? If so which one: input or output buffer ? A post in the knowledge base says DAQmx does this automatically.

Rgds

[Kevin_Price]

Questions:

1. Does DAQmx really support counter DMA ? I thought I need DAQmx base 2.0 for this ?

2. How can I make sure that DMA is used and not IRQs ? Is it enough to declare continous sampling when defining the task in the MIE (Measurement and Instrumentation Explorer)

3. Can I ask LabView if this task uses DMA ? To make sure I set DMA with the channel proerty node, but got -200371 (cannot define another channel on same device). I assume this is because I declared the task in the MIE already.

4. Does it make sense to set the buffer size ? If so which one: input or output buffer ? A post in the knowledge base says DAQmx does this automatically.

1.  Regular DAQmx definitely supports DMA on a PCI device.  DAQmx base is a subset of regular DAQmx.  I haven't needed to use it, but my understanding is that it's needed for certain low-cost USB devices and for DAQ programming under Linux and Mac OSes.

2.  Generally, DMA will be used automatically whenever possible.  You usually have to go out of your way to request the use of interrupts instead.  I can't comment on your use of a global task in "MIE" because I never use them.

3.  Yes there is a DAQmx property node that can be queried to find out if a task is using DMA.  I don't recall if it's a Channel property or a Timing property, and you have to dig through some sub-menus to find it.

4. DAQmx will choose a buffer size automatically if you don't explicitly set it yourself.  It's possible to override with manual settings, but you typically won't need to.

Advice: create the task programmatically by adapting one of the shipping examples.  If you want to timestamp the encoder edges, you should be performing either period or frequency measurement (1-counter) using the "Implicit" version of DAQmx Timing.vi   If you keep running into errors, post the code.

-Kevin P.

[Stefanich]

Hi Kevin

Thanks for advice again.

I found the last bug in my setup and this thread can be closed.

The reason for the rare -200141 I had was unclean edges on my counter gate. I obviously I had double edges causing event triggering within microsecond distance. This was too fast for the buffer mechanism. Adding the usual tantalums to the 5V supply of my tacho buffer hardware removed the problem. I can now read thousands of events without problems.

I found hints on noise in the forum, but searched for software bugs first.

I will retry to go back to the counter on my USB device DAQpad-6016 to checkout if the USB data transfer is fast enough.

Rgds

Eric