AngularEncoderInitialAngle property can't set with same precision as the encoder counts

[TimER]

Creating Angular Encoder Channel. X4 encoding for quadrature encoder. The resolution of the encoder is 900 pulses per revolution. With the X4 encoding I can get resolution of 0.1 deg/count (3600 pulses per revolution). However, when using the AngularEncoderInitialAngle property to set the initial angle I can only set the initial angle to within 0.4 degrees, which coresponds to the basic encoder resolution (900 counts/rev), not the resolution I get in quadrature during operation (3600 counts/rev). Why can't I set the initial angle as precisely as the resolution that I get in quadrature during operation?

[Danubio]

Hello TimeER,

Do you receive any error number or description when trying to run the program using this property while the encodig type is set to X4?

Regards,

Daniel C.

[TimER]

Hi Danial,

No, I don't get errors. When I create the CIChannel I set it up with X4 encoding and the Pulses Per Revolution is 900. Once the task is started it counts correctly with a resolution of 0.1 degrees. The problem is that if I set the initial angle to something like 0.1, start the task, and read the position it will be 0.4 degrees even though the shaft hasn't moved. Trying other values for initial angle has shown me that it only accepts values that are even multiples of 0.4, which just happens to correspond to 900 counts per revolution. I would have hoped that I could set the initial angle to within the resolution of the quadrature counts (900 * 4 = 3600 counts/rev = 0.1 deg/count)

Thanks,

Tim R

[TimER]

Sorry...Daniel misspelled your name

[Danubio]

No problem TimeER.

Regarding to your question, the reason you cant set an initial position of 0.1 degrees is because the counter has only 900 physical pulses (slots) per rotation. That means that the minimum phisical space possible between one slot and the other is 0.4 degrees. The type of encoding (X1, X2 or X4) is a software action, but in physical terms, you can not count as a defined position the half or the fourth part of a pulse, so it will always be multiples of 0.4.

Regards,

Daniel C.

[TimER]

Setting the initial position is a software action also. Nothing physical is taking place at all. If software can be written to encode the position during operation, then software can be written to take into account the encoding type and set the initial position accordingly. I have confirmation from a support request with NI that this is "built in" behavior. In my mind it's a bug that should be fixed. Thanks Daniel for your replies and for looking into this. Unfortunately I will have to just live with this bug.

[Kevin_Price]

I agree, TimER, that the resolution available for setting initial position should match the resolution presented when reading the (scaled) angular data.

Here's a workaround idea for you:  do your own conversions between counts (ticks) and degrees.  Configure the measurement with units of "ticks" and set the initial position as an initial "count".  Read the data as u32 unsigned integer counts, use the "To Long Integer" conversion on the u32 data to produce a signed position in units of counts, and *then* convert to degrees yourself.

A bit more roundabout, but you'll get the resolution you're after.   Meanwhile, you could write up your suggestion for supporting better resolution on "initial angle" over on the DAQ Idea Exchange.   Note that it'd make sense to make sure the 'z index value' can also support that same resolution -- I don't have hw at hand to see how it behaves currently.

In some respects, I think I'd prefer that an initial angle could be set to any floating point value, regardless of base encoder resolution.  That would be much more helpful for the fairly common case where the initial angle is used to represent or compensate for a known calibrated angular offset.  On the other hand, that'd put us back into a situation where there'd be different resolution behavior depending on the choice of "angle" vs "ticks.'   So maybe it'd be just as well to support only the resolution implied by the combo of Pulses per Rev and 'decoding type' and let any further offsetting be left to the application programmer.

-Kevin P