Position measurement doesn't roll over correctly

[Sirmutt]

I'm trying to measure position (in tick counts, not angle).  I set the Z index, counts per revolution, and initial position.  If I have 400,000 counts in one revolution and Z index of 40,000 (since I'm using X4, I have to enter 10,000 which is odd), I can never get a position less than 40,000.  Rather than rolling from 400,000 to 1 and starting to count up, it just keeps counting up until the next home pulse at which is then goes to 40,000.  So, in this example, it goes from 440,000 to 40,000.  Now, I could compensate for this with math, but it's more problematic when rotating counter clockwise because rather than going 3, 2, 1, 400000, it goes 3, 2, 1, 4294967296, 4294967295...  It's a lot less pleasant having to deal with 2^32.  Still could deal with it though.

Why doesn't the counter reset to 0 when rotating clockwise or 400,000 when rotating counter clockwise.  I would expect the only valid range for data to be 0 to 400,000 and it would roll over when it reached one of those limits.  But I can't make it work that way.  Am I missing something?

Thanks.

[griffindore]

Hi SirMutt,

I assume that you are basing your program off the Measure Angular Position.vi example found in NI Example Finder and changing it to return U32. If you're doing something different, please let me know. From your explanation, it sounds like you want a Z index of 0 and not 40,000. Could you explain why you decided to use 40,000? Did you just want to set an initial angle? If so you may want to set the initial angle input instead. If you make that change, I believe the screenshot below is an easy implementation to map the 399,999 to -399,999 to a 0 to 399,999. Please let me know if this helps!




Message Edited by lion-o on 08-12-2008 05:49 PM

[Sirmutt]

Our application actually has two read heads measuring position on a Gantry.  They are redundant signals used to give position.  These two encoders are located at ~40,000 and ~450,000 ticks out of 555,000 total for one revolution.  When the home pulse is received from one, we know it is located at 40,000 and likewise for the second, it is at 450,000.  Zero is actually not a valid position for us, it goes from 555,000 to 1. 

It appears that the home offset provided by NI doesn't really do what it should.  It just moves the starting value but doesn't roll over at 0 (I assume even if measuring degrees, it would continue past 360 rather than starting over at 0). 

I have already incorporated math to give the proper position, not disimilar to your example except I didn't convert to I32, but thought this functionality should be different. 

If I'm still missing something, please let me know.  Thanks for the response.

[griffindore]

Hi SirMutt,

The counter should be reset to the Z Index Value when your home pulse is received on Z. I believe the confusion comes into how the "Pulses per Revolution" input is used for the Angular Position. The "Pulses per Revolution" could give the assumption that the counter would reset to 0 when the pulses per revolution is exceeded, but it is really just used to calculate the Degrees or Radians if you are returning these units. You are correct in assuming that if measuring degrees, you would continue past 360. This information can be useful if you wish to know exactly how many rotations you've completed. Phase wrapping (both in degrees or just in counts) will have to be done manually outside of the DAQmx driver. Please refer to this DevZone for the equation which calculates degrees out of the "Pulses per Revolution" and counter value. As you can see, it does not account for phase wrapping. I hope this information helps. Have a great one!

[Sirmutt]

I see.  It isn't as easy as the equation implies though.  That's all fine and good if you're rotating clockwise and things are counting up.  If you're rotating counter-clockwise and thus counting down, the counter goes from 0 to 4294967295.  Thus a case for CW and CCW rotation needs to be implemented. 

I was hoping it was just a user error but it appears I will need to do that math.  Not a big deal. 

Thanks.

[griffindore]

You're right about having to handle decrementing below 0. We're returning the value of the counter itself which will roll from 0 to 4294967295 if counting down. The good news is that you can just convert from U32 to I32 like in my above example and instead it will count from 0 to -1 etc. I haven't tested it in Degrees and Radians mode to see if it's handled appropriately. I believe the first image with the quotient and remainder function takes care of both handling the negative counter values and exceeding the Pulses per Revolution when returning ticks. Let me know if that workaround doesn't work for you and you need some more assistance with the conversion so that we can attach a useful workaround to the forum for the community.