Third Party U 64 Control, Used bits 25 most significant

[KWaris]

I spent the whole day at work trying to work out some calculation and the simple fact that I dont know and could not find any literature on using x number of bits from a U64, I returned home with no results for today.

Dear Experts Please help.

I have on the machine an endat encoder to measure the speed in RPM of the shaft of a motor. I used manufacturers provided RT vi to acquire the position data. This is a 25 bit encoder so the RT vi position indicator gives a 25 bit value. This value is acquired using a U64 indicator. I found that only the most significant 25 bits are used from this U64 indicator.

This 0 to 2^25 bit value ( 0 to 33554432) corresponds to 0 to 360. The manufacturer gave the following instructions to convert it into RPM.

Timed loop period to 1000 ms

Take difference of the current position value from the previous position value and divide it by 2^24 and multiply by 60.

I can read the current position. Then use the shift register on the timed loop to read the previous position value. Both are acquired using U64. When I subtract the two, the results fluctuates as below.

The difference, some random value, the difference, some random value, some random value, the difference.

I dont know why this is occuring. When I can read the current and previous position values, why the difference is not a correct value. It looks to me that it is perhaps something to do with the bits of the U64 indicator.

Any comments will be much appreciated

Kind Regards

Austin

[Darin]

Are you sure you aren't "rolling under" the U64 by subtracting the larger value from the smaller one? I usually use a Max & Min function to be sure I subtract the min from the max when dealing with Uints. Or just coerce to a I32.

[drjdpowell]

Are you being sure to throw away any bits > 25 when the encoder rolls over? The code below should give the correct U25 difference even though it’s using U32’s:

Added later: actually, the fact that the “random values” alternate with the good ones suggests some other problem, unless you are reading the encoder about two times a revolution.

[ShaunR]

You state that only the most significant bytes are used. This is a little unusual since an encoder is usually a counter. It is more likely that the number is little endian wheras LabVIEW numbers are big endian (i.e. you may have to reverse the bits to get 0-2^n).

[GregR]

It is more likely that the number is little endian wheras LabVIEW numbers are big endian

It definitely could be an endian-ness problem, but your characterization of LabVIEW is not quite right. LabVIEW flattens to big endian but in memory (any typed data on a wire) it matches the endian-ness of the CPU. Since all our desktop platforms are now x86, they all run as little endian. So the problem would be that his data is big endian and LabVIEW is treating it as little endian. Don't mean to be pedantic but I don't want someone to come along later and convince themselves all LabVIEW data is big endian.

[ShaunR]

It definitely could be an endian-ness problem, but your characterization of LabVIEW is not quite right. LabVIEW flattens to big endian but in memory (any typed data on a wire) it matches the endian-ness of the CPU. Since all our desktop platforms are now x86, they all run as little endian. So the problem would be that his data is big endian and LabVIEW is treating it as little endian. Don't mean to be pedantic but I don't want someone to come along later and convince themselves all LabVIEW data is big endian.

I always get the terminology round the wrong way (has to do with a boolean array in LabVIEW having the LSb on the left). Thanks for pointing it out.

So. What I said before, but swap the terms.

[Phillip Brooks]

This 0 to 2^25 bit value ( 0 to 33554432) corresponds to 0 to 360. The manufacturer gave the following instructions to convert it into RPM.

Timed loop period to 1000 ms

Take difference of the current position value from the previous position value and divide it by 2^24 and multiply by 60.

I can read the current position. Then use the shift register on the timed loop to read the previous position value. Both are acquired using U64. When I subtract the two, the results fluctuates as below.

The difference, some random value, the difference, some random value, some random value, the difference.

One sample per second?

If your device is rotating at around 30 RPM you may see alternating signs in the difference (random values) when samples occur across the zero reference.

You could increase the sample rate and adjust your calculation accordingly, but may occasionally experience 'random' values whenever your samples occur over a zero crossing.

Create a shift register to store the sign of the last few differences. When the sign of the current difference doesn't match the previous values, add or subtract 2^25 to compensate for the zero crossing.

Edited July 20, 2012 by Phillip Brooks