On Thu, Jul 5, 2012, at 01:08 PM, andy pugh wrote:
> My initial impression is that the software encoder does not handle the > wrap as well as it might. It probably ought to add delta_counts * > scale to the position, not recalculate the position from total counts. > The magic of twos-complement means that calculating deltas on signed > integers handles the wrap automatically. I respectfully disagree on this part. Counts are counts, and integers can be accumulated indefinitely with no error. Floating point math can be imprecise, and accumulating "counts times scale", where scale is a float, could result in accumulating errors. Thinking about it a bit more, it definitely will result in accumulating errors. Suppose your scale is 30000 counts per inch. So the amount you want to add to the accumulator each count is 0.000033333". In either scheme there will be some error, since that number cannot be exactly represented as a float. Floats have a resolution of 24 bits (the other 8 are used for the exponent). So the basic error will be 1 part in 2^24, which isn't bad (for example, 3.6 micro-inches on a 60" long travel). If you are accumulating counts as an integer, and then multiplying by the scale factor, the error will always be 1 part in 2^24, regardless of how far you travel. But it can be a lot worse if you are accumulating chunks of 0.000033333" as floats. Suppose the axis has moved 35 inches. On the next count, you will be adding 0.00003333" to 35.0000". The 0.0000333333" value starts out with 2^24 resolution, but it gets shifted right during the add, because the exponents have to match before you can actually perform the addition. In this case, the shift is 20 bits, leaving the scale factor with only 4 bits of precision. Working the example in decimal floating point notation makes it easy to see. Floats have about 7 decimal digits of resolution. So the scale factor would be represented in decimal as 3.333333e-5. The current axis position is 3.500000e+1. To add them together, the scale factor gets shifted right 6 digits, so it becomes 0.0000033e+1. So on every count, you miss 1% of your actual travel. The situation gets much worse if you travel further. Consider what happens when the axis reaches 1000 inches (in the decimal case). Axis position is 1.000000e+3, so the increment of 3.333333e-5 needs to be shifted 8 positions. The result is 0.000000e+3. Adding (or subtracting) that from the accumulator will have no effect, so the output of the encoder block will never change - even if you start moving back towards zero. It will simply be stuck. By comparison, if you are accumulating integer counts and then converting to float, you might reach a point where you don't see a change in the float value on each count, but the counts _are_ being recorded, and the float output will continue to increase every couple of counts, when its resolution permits. And when you reverse and start moving back towards the origin, the accumulator will correctly track the position. There is another issue, which could be considered good, bad, or irrelevant, depending on your point of view. HAL allows anything (including scale) to be changed at any time. Suppose you move an axis for a while, then change scale, move it some more, then change scale back to the original value. The current implementation will have a position jump when you change scale. But it will always know where it is, because it is accumulating counts. If you change scale back to the original value, your position will be correct, even if you moved while the scale was wrong. The proposed implementation avoids the position jump when scale changes, but if you move after changing the scale, you lose track of your original position. The accumulator now contains some motion at the original scale factor, and some motion at the new scale factor. Avoiding the jump might be considered good. Losing your absolute position is bad. And the whole issue is probably irrelevant since few people change scale on the fly. But I prefer the current implementation, and would think hard before changing it. If there is a concern about rollover, then change the accumulator to 64 bits. But it should still be an integer recording counts, not a float or double recording scaled length increments. -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
