AI timing signals (USB-61620)

[Ammad156]

Hello everyone,

I wanted to know the best way of setting-up my voltage acquisition in my experiments. I want to capture a voltage signal across a shaft contact for 1 shaft revolution. I have setup the sampling rate and number of samples required to match the shaft speed to give a signal per rev.

However, I want to capture the signal after every n revolutions. The shaft would be running at constant speed and I have been defining an acquisition frequency that saves the signal after T seconds using the Onboard Clock. I am not sure if this is the right way to do this, i.e. would I capture the same signal with respect to shaft position as the first one? Should I use Hardware-timed acquisitions, as one of its advantage is the timing between samples is deterministic? There are multiple timing signals like Sample clock signal, sample clock timebase signal, convert clock signals, etc. Im not sure which one would be best for this case.

The last option I want to look into is using the encoder signal from the motor to trigger the acquistion, but again this is the last option. If i can get a reasonable performance from setting up timing that would be best, as the speed is constant.

Thanks,

Ammad. 

[Kevin_Price · Accepted solution]

Free tip from someone who started capturing encoder motion with NI DAQ devices back in the 1990's:

No, your speed is not actually constant, as you'll soon see with a good hardware-clocked measurement.

You first need to answer a key question -- if you had to pick only one, which relationship is the most important:

AI signal vs. rotational position?    OR     AI signal vs. time?

Since you are even considering using the encoder signal to drive your acquisition, the rest of this post assumes you care most about AI signal vs. rotational position.  I don't know what your instrumentation is, but here's what I'd *want* to do:

1. Configure the AI task to use the encoder signal as its sample clock.  Then it will capture 1 sample on each active edge of the encoder signal.  The AI data will be *directly* correlated to angular position.

2. Configure the AI task for finite sampling, where N samples represents some integer # of full shaft rotations.

3. Configure the AI task to be triggered by the encoder's Z-channel (or "index") signal, if you have one.  This way you always start your capture at the same physical rotational position.

Note: you probably won't need to do any configuring of the convert clock (which controls multiplexing when there are multiple channels in a task) or the sample clock timebase (which you would specify if you need to *derive* a sample clock from it via integer division)

-Kevin P

[Ammad156]

Hi Kevin,

Thank you for taking time out to answer my question, really appreciate it.

Now that I think of it, I agree its ideal to have constant speed. In that case it would be more important to have AI signal vs rotational position. If the acquisition time is constant for each signal, would it be correct to assume the second relation is fulfilled on its own or am I still missing something.

My encoder has 3 channel, by Z are you referring to the channel that gives single pulse per half revolution?

Thanks again.

Ammad.

[Kevin_Price · Accepted solution]

The "Z-channel" I referred to would typically produce 1 pulse per full revolution for encoders I've worked with.  The pulse width would correspond to either 1 full cycle of A or else 1/4 cycle (which is the width of 1 specific quadrature state).

As to time vs position, it sounds to me like you're still missing something.  Specifically, it sounds to me like you haven't yet encountered real-world motion data.  When you do, you'll find that what you *think* is constant speed is not quite so perfectly constant after all.  So you can't automatically assume that sampling at equal time intervals will also give you equal position intervals.   And vice versa.   That was the reason I presented the problem of picking one or the other as more important.

All that said, some systems do indeed have smaller speed variations than some measurement applications are concerned with.  But without more info to go on, I wouldn't want to assume that from the start.

-Kevin P

[Ammad156]

Hi Kevin,

I have developed a LabView program using help from user manuals and online blogs. The block diagram is attached as image. I have tried to implement what you suggested before to ensure the Analogue voltage signal acquired uses encoder signal as sample clock and gets triggered by the Z/index channel. I have also attached schematic of my setup to help you better understand what I'm trying to achieve and if you can suggest any improvements.

I have not tested this program with my setup yet.

I am not very proficient with LabView but I can learn quickly so please let me know if something seems very wrong.

Thank you again for your time and valuable feedback,

Regards,

Ammad.

[Ammad156]

An update on the problem. I tested the program today and initially it gave error DAQmx Read Error-200278 because I set finite sampling with while loop. I changed sampling to continious.

However, should I set the sampling rate and number of samples to correspond to 1 shaft revolution at given shaft speed? Or any better alternative?

Thank you in advance.

[Kevin_Price]

By using the encoder ch A as the sample clock, it becomes very easy to capture exactly 1 rev worth of AI data -- just request the appropriate # samples per read.  If ch A has 1024 cycles per rev, every block of 1024 samples will represent 1 rev.  Your spatial resolution increment would be 360 degrees / 1024 samples.

Combine that with your use of the Z channel as a start trigger, and you can know exactly where each 1 rev worth of samples starts and ends.  So you've already done most of what you need!

The only other tidbit I'd offer is that the "# samples" input to DAQmx Timing and the "# samples" to DAQmx Read serve different purposes.  The one for DAQmx Read is the important one for you.  The one for DAQmx Timing is often not relevant for continuous sampling.

If you find this confusing, join the club and consider adding kudos to my complaint / suggestion.

-Kevin P

[Ammad156]

Thanks so much Kevin.

One extra thing that will make the problem a bit more complicated in the future. The disc shaft will later be driven by the motor through a belt-pulley drive having a ratio of (32/18) (disc being slower than the motor). There is no room for installing an encoder on disc so the motor encoder will be used again. Now the index position of disc will lag by the motor index position. In this case is it better to use counter (number of revolution of motor) to trigger the acquisition as the Z channel might become at different position at given time? Also, is it possible to continue acquisition and run the counter in parallel?

Thanks again!

[Kevin_Price]

Adding the belt and pulley drive definitely makes the Z-index trigger less useful.  Two possible ideas:

1. Any way to add some kind of once-per-rev sensor to the disc?  It sure would be helpful to be able to trigger off a signal with a known correspondence to the disc's physical rotational position.

2. Your ratio means that the disc position for each motor Z-index will cycle over 9 distinct physical positions.  Not knowing much about your system or the needs of your app, one *conceivable* approach is to trigger off the motor and then capture in chunks of 9 disc revs at a time.  (Note: this corresponds to 16 motor revs).   Each set of 9 disc revs will start from the same physical rotational position, and it will correspond to the motor encoder's Z-index -- making the correspondence repeatable across many runs.

Yes, counter and analog input tasks can run in parallel.  You'll probably want the app code that manages them to be in parallel as well.

-Kevin P

[Ammad156]

Hi Kevin,

Is there an easy way of triggering the AI acquisition after every 16 revs of motor? I have been looking into it and from what I understand it can be done using digital counter and using case structure to check when the counter reaches 16000 (for 1000 PPR) to trigger AI read.

Thanks.