AI and counter sync + USB signal stream (USB-6210 vs. USB-6341)

[jAwA11]

Dear all,

I am at a stage of suitable hardware identification for the following tasks:

• reading 5 analog inputs (AIs) simultaneously, voltages at a rate of (at least) 10 kSps,
• implementing 2 capture inputs using timers (edge detection with timestamps), square wave input with 50% duty cycle and around 1.5 kHz freqency and varying pulse width / frequency (originating from 2 hall sensors, representing DC motor rotation speed and direction, quadrature signals), resolution of timestamps should be (at least) 50 ns,
• AIs and counters should behave deterministically and should be somehow synchronized,
• data should be transferred via USB to a host computer equipped with Matlab Data Acquisition Toolbox (unfortunately no LabVIEW).

I identified both the USB-6210 and the USB-6341 as potential hardware candidates to fulfill the tasks mentioned above, but after studying several documentations as well as forum topics, I am still a bit puzzled if both fully do the job and if my approach described below is working properly.

Counters: I intend to use the internally available 20 MHz timebase as the counter source to realize 50 ns timestamp resolution. The external hall pulses are used as sample clock (around 1.5 kHz, see above). Since the pulse width varies, the sample clock is not constant.

AIs: Using an internal 10 kHz clock signal derived from the 20 MHz timebase for hardware timing and starting (triggering) both analog inputs and counters simultaneously should result in the required synchronization and deterministic behaviour.

Does this work? Any other recommendations?

Next is USB data transfer: All 5 AI and 2 counter input data should be properly transferred to the host computer (corresponding rates are given above). USB-6210 is capable of 4 USB signal streams, USB X series device (6341) offers 8 of them. Unfortunately, I could not figure out the exact meaning of the phrase "signal stream" yet. Do I need 1 signal stream per input (would be 7 for my described application) or 1 stream for all analog inputs and 1 for the counter inputs (would result in 2 streams for my application). Are there any details available on this USB signal stream approach (more than NI Signal Streaming)?

Any challenges for the described application which I might have overlooked? USB 6210 seems to a have very limited number of input PFIs, maybe even too low for my counter input application?

Looking forward to your comments and hints.

Regards

jAwA

[Kevin_Price · Accepted solution]

1. I'll recommend the X-series 6341 over the M-series 6210 for the sake of counter/timers.  It has more of them, and they each are more capable.   It may also have a larger on-board FIFO for counters which can be important in some tasks though I don't think you're currently dealing with one of them.

2. Your general notions about timing & sync are sound.  You'll be able to share and route signals that help ensure sync and determinism between the timestamps for your various tasks.  Note that for counter input tasks, you should plan to configure the "Arm Start" trigger rather than the regular start trigger.

3. This isn't authoritative, but I believe the # signal streams will correspond to the # tasks.  For you, that'd be 1 AI task and 1 or 2 CI tasks.  (Not clear if you have 1 encoder with 2 quad channels which would require 1 CI task, or if you have 2 encoders with 4 quad channels.)

4. Watch out for hall effect signals that aren't pristine.  Digital filtering is available and probably better on the X-series than the M-series.

5. Strictly speaking, edge detection is a kind of Digital Input task that produces samples but no timestamps.  Ideally, I'd want to parallel wire to both digital inputs for change detection and counter inputs for quadrature position decoding.   Then I'd sample the 1 or 2 encoder counters using the internal "change detection event" pulse.  I'd set up another counter to timestamp that change detect pulse as well.

-Kevin P

[jAwA11]

Dear Kevin,

thanks for your immediate response and your valuable comments. This strengthens my mind that I should go for the 6341 device. For clarification, there is one encoder with 2 quadrature channels.

I believe I will come back with practical issues when the project is at realisation stage.

Regards

Jan

[jAwA11]

Dear all,

Sorry for putting up this topic after quite a while now. The functionality described in my first post is working properly now. In addition I have realized a motor control using external H-bridge circuitry which is controlled by the digital outputs of the NI USB-6341.

My intention is now to immediately stop the motor when the position counter (with quadrature encoding X4) reaches a defined target position value. In my current implementation I am using a buffer size of 1 sample for the position counter measurement so that every new position value is immediately send to the host computer, the value is checked against the target and, if identical / reached, a digital output is set to stop the motor.

Due to latency of USB communication (and lack of low-latency Hardware-Timed Single Point Output capablility of the USB-6341 device), the resulting positioning is not very accurate.

My question is now: Is there any possibility with this X-series device to set a digital output when a counter has reached a defined limit / value without data transfer to the host computer, i.e. realization in USB-6341 hardware itself?

Regards

jAwA

[Kevin_Price]

The only way I know of is through setting up counter properties related to "terminal count", but there will be some implications.

1. You'll probably need to add a simple software layer to your position tracking to handle the offset between what the counter hardware considers the "terminal count" position and what your app might naturally want to treat as your 0 position.  The encoder would need to be defined with a non-zero initial count or initial position.

   (Note: once upon a time I found some quirks/limitation when trying to set a non-zero init position in engineering units.  It futher solidified my "old-school" bias to do all my own counter scaling while directly interacting *only* in terms of u32 counts.  The issue may be fixed or not applicable for your device, just be sure to verify that it behaves as needed & expected.)

2. You'd need to set up the counter to either Pulse on terminal count or Toggle on terminal count.  Either way, you need to think through the logic and timing of what you need to enable/disable, how you're going to reset, how to get yourself moved back out of the disabled position, etc.

   It may turn out that you need to employ a 2nd counter that gets triggered or enabled by the encoder counter's terminal count pulse or state toggle..  The reason is that you would get to define pulse characteristics on the 2nd counter that may be more suitable for your functionality.

3. You'd probably also need to explicitly route the "CtrXInternalOutput" signal out to a PFI pin (these internal signals aren't routed out by default for input tasks).

-Kevin P

[jAwA11]

Dear Kevin,

thanks for your help. I followed your proposal and it works out fine for my application.

The only issue I came across is the initial position value when using quadrature encoding counter type X4. The value set by my coding is internally always multiplied by a factor of 4; thus I loose this factor in positioning accuracy. This was already described here

http://forums.ni.com/t5/Counter-Timer/DAQmx-Quadrature-Encoder-Initial-Position/td-p/3168932, but unfortunately no solution was given. Any ideas?

One more general issue: I have routed several internal PFI connections. From Measurement and Automation Explorer's 'possible connection table', I understand that there are direct and indirect routes.

When trying to route the 20MHzTimebase to Ctr1Source, I get a 'resources conflict' error when trying the following code (as I said some time ago, I have no LabVIEW access; thus I am calling some Mex C functions from Matlab environment)

status = daq.ni.NIDAQmx.DAQmxConnectTerms (...
    '/Dev1/20MHzTimebase',... % sourceTerminal
    '/Dev1/Ctr1Source',... % destinationTerminal
    int32(daq.ni.NIDAQmx.DAQmx_Val_DoNotInvertPolarity)); 

When changing 'Ctr1Source' to the terminal name 'PFI3' with the code

status = daq.ni.NIDAQmx.DAQmxConnectTerms (...
    '/Dev1/20MHzTimebase',... % sourceTerminal
    '/Dev1/PFI3',... % destinationTerminal
    int32(daq.ni.NIDAQmx.DAQmx_Val_DoNotInvertPolarity)); 

everything works fine, but my understanding is that this takes one indirect route (which again causes some conflict when I try to add an additional indirect route). If I could directly route '20MHzTimebase' to 'Ctr1Source', this would give me one more 'free' indirect route. At least, this is my current understanding.

Therefore: Can I control which route is indirect, which is direct? Can I get any information about which route is possible together with others or where potential conflicts could occur? At this moment, it is a game of try and error...

Thanks again.

Regards

jAwA

[Kevin_Price]

Unfortunately, the behavior about X4 decoding and resolution sounds like an issue in the driver implementation, probably related to the thing I remembered and cautioned you about.  I'm not aware of any workaround.  

As to direct and indirect routes, they are pretty much fixed by the board hardware design.  In my experience, it seems that indirect routes will typically consume a counter as a means of providing the signal route.  I don't know of a way to predict which one may get used.

-Kevin P

[Kevin_Price]

I played around a little with some of those encoder settings.  Really not a fan of some of the chosen terminology or overall implementation.  NI is very careful about what they call a "bug", but I'd say that some things are definitely "messed up."   Caveat: based on a little tinkering using a simulated MIO device.  But also based on memory of related "messed up-ness" when working with real hardware some years back.

Setting a small negative initial position for a linear encoder and then querying that initial position returns a value in the order of +10^9.  Now I've been around counters enough to know *what* is going on, but that's definitely "messed up" as an API.  (Internally the count register is an unsigned 32-bit integer. The equivalent to -1 is represented as 2^32-1.)

Anyway, I may have found a little head fake you can do as a workaround for the limited resolution.  Can't be sure but it seemed to work on my simulated device.

First configure the encoder task as X4, and *claim* that the pulses per rev or distance per pulse is 4x as fine as reality.  Also set your desired *real* initial position, which should now be allowed because (so far) the task thinks your encoder resolution is 4x better than it really is.  Then call a DAQmx Channel property node to set the correct resolution.  When I did this on a simulated device, the task held onto the original setting for initial position.   Give it a try on your real hardware, there's a chance it'll be a workaround.

-Kevin P