USB-6216 encoder continuous sampling

[Jason93]

I'd like to use my USB-6216 DAQ to collect encoder and two AI channels in continuous sampling mode. If I use On-demand it works fine, but I need to sample faster than about 0.05 seconds. If I switch to conintous mode to collect at say 1000Hz the counter says I need an external clock. It seems like my USB-6216 cannot do this (even though it says it has 2 counters/clocks) Am I out of luck? I have successfully used this method using my cDAQ and an AI module and a DIO module but I think that is because the cDAQ has it's own clock? in addition to the DIO module? 

Regardless I'd like to use my USB-6216 only. Is it possible to sample what I mentioned above in continuous mode without any other hardware. I'd prefer to use (the older) Signal Express as all I want to do is collect a few data sets not write a bunch of labview code to 3 ten second data files.

thanks all

Jason

[Kevin_Price]

Unfortunately, no your USB-6216 device doesn't support this.  I wanted to point you to a "correlated dio" example that's supported by *most* M-series devices, but I found this instead.

-Kevin P

[Jason93]

Kevin thanks

Sounds like I'm hosed. I know a decent amount about DAQ but somethings perplex me.

Interesting it says I can external clock on PF10. Does that mean I can generate a pulse train from a different device even a function generator to do the clock? Am I nuts?

Also could I attach another USB DAQ that is doing nothing other than providing the Clock? Is that possible? It seems like my cDAQ solution I mentioned above was something like that. Digitial IO module does one thing and the internal cDAQ clock did the other.

Thanks All

Jason

[Kevin_Price]

No, sorry, hosed is where you're at with the USB-6216.  Its whole DIO subsystem doesn't support the ability to buffer and hw-clock digital IO, regardless of where that clock might come from or where you connect it.  Probably the external clock on the PFI pin stuff you mention is only for analog IO tasks (and probably also counter tasks).

With the cDAQ, the chassis would have directly supported hw-clocking for (at least some) DIO modules.  It would probably also support the correlated DIO approach of sharing the AI task's sample clock.  I'd prefer the latter approach for the excellent hardware sync of the sample times.

A fairly terrible workaround might *possibly* be to capture the encoder channels as 2 additional AI channels in your AI task.  Then you'll have to implement your own algorithm to perform quadrature decode on the analog data to convert to encoder position.  It can be done, but be prepared to spend some time making it reliable and bug-free.

-Kevin P

[Jason93]

Kevin

thanks  for the help

now I have a definitive answer. Unfortunate my cDAQ is rack mounted in another lab. 

I can do the analog thing and programming for me would not be hard to extract the angle. Ideally I’d like to use SignalExpress drop in an encoder and a AI current measurement grab 3 sets of data and be done. It’s for a college course. But this issue has been there for me for a while. I only look into solutions this week of the semester. For the year. 
but now I know for sure it cannot work with my hardware. I can just buy another cDAQ.

or a cheaper option would be a tachometer mounted to the motor as I really don’t care about angle as the class only cares about RPM

[Kevin_Price]

Yeah, if you just need RPM rather than angle, I tend to agree that an analog tach ought to be a simpler way forward.  You might also consider setting up the counter for frequency measurement, but that'll result in variable rate sampling from the counter task, where correlating the AI sample times to the frequency measurement times won't be trivial either.  If nevertheless interested, search for info on the "Arm Start" trigger for the counter task, be careful to figure out whether the 1st freq measurement is valid or not.  More info here.

Despite my general advocacy for counters, I'd still go with the tach if one's available that produces a good enough measurement for your purposes.

-Kevin P

[Jason93]

Thank Kevin

I will look into suggestion 2.

On the analog tach. I have not found what I'm looking for in this area. Maybe built in Tachs but if I want to mount one to the shaft of the system (its just a DC motor, shaft gear box benchtop system) do you have experience on where to go for that? Mount to a 0.5" to 1" shaft? Analog tach? I'd pay mostly anything. I don't think I'm searching for the right thing? type tach in google and 99.5% is automotive. The encoder is part of the motor so I will have that capability in the future should I replace my 6216. I'll keep searching anyway for a tach

thanks again

Jason

[Kevin_Price]

I don't have time right now, but over the weekend I'll see if I can dig up something I (or someone else, I just tend to have a clearer memory my own particular words to search for) posted before that'll help with some of the "dirty work" to sync AI with a CTR frequency task.

I'm afraid I don't have any particularly relevant knowledge about analog tachs, especially at that kind of shaft diameter.  I thought you already had something specific in mind.  So I'll stick with the CTR frequency approach.

-Kevin P

[Kevin_Price]

I didn't manage to turn up any examples that fit exactly.  They may be out there, but I didn't find them.

The one I thought was closest came from over here.  It shows how to calculate all the sample times corresponding to interval period measurements (and periods are just the reciprocal of frequencies).  It also shows how to use an Arm Start trigger to sync the start of the counter task with an analog task.

A different approach that would be easier if your app allows for it -- use the encoder as an external clock for your analog task.   Then you'd get samples equally-spaced in *rotational position* instead of being equally-spaced in time.  This can be good enough for some apps, and even preferable at times.

-Kevin P