0.005 error randomly accumulating over 30.000 inch travel, solutions etc ??

short jogging results are consistent, plus or minus 0.0001 to 0.0003, within limit for a 50 yr old machine. The random accumulation of errors across long travel however have me concerned. At distances under 1-2 inches the error is non existent but over long runs it is accumulating. I have looked with a scope and the signals look really good, so I am unsure as to where I should look , it's a 3.00 tpi running at 300ipm with a 4096 ppr with index. 

Is is possible that the quadrature count is not fast enough to measure all pulses or is there  known math errors is with certain encoder type ? 

How did i measure the error, I put my Mititoyo Rapid tenths indicator on lath bed, zero'd out and then set g28, then I command out to z32 and call it back to g28, it stops at the dro indicated 10.5013 each time, but the indicator shows the error accumulating by 3-6 thousandths each time it comes back to g28 position. no noticeable Ferror showing in halscope. However moving the axis 1 2 or 4 inches and calling back to g28 does not produce such a large error I see no measureable error. I could understand variation in the length of the ballscrew, that's expected, this is strange as it is accumulating in a semi random way. 

It sounds like something is moving. Is it continuing to accumulate on multiple runs? If not, what about thrust bearings. The Cinturn is a box way machine, are their slippers under the saddle that could be binding?

it is accumulating every run, and the machine is tight and clean with excellent ways and screws. I am going to check the slipper tomorow, but the error is stacking up. short move testing indicates it is unlikely to be a lash or a way issue specific to the stopping area in the g28 command. however the exact number of encoder revolution may shed some light on this. I am looking over the motion control code, I suspect the floating point is being truncated, that might offer a plausible explanation to the error accumulation. if it was just randomly 5 7 3 8 3 I would accept that it is hardware, in fact some of that lash is to be expected, but when it's going up adding almost exactly 5.5 thou every time, that's not mechanical. was just outside remeasuring, it's 5.5 thou every time

this is the EXACT number of required encoder revolutions for this move

241.5686724609375 <

---

this is a very long number

I thought it was a 4 pitch screw in 1976.

5 mills out of 30 inches is a relatively huge error
Can you check the shaft position?

(a 5 mill error should be about a 5.4 degree shaft position difference)

Is it possible you have a loose encoder wheel/coupling?

I'll check again, I'm bringing my 4mhz scope home from work today as well. i the spindle encoder is dropping out around 2600rpm, encoder appears to be sending valid data.

4096ppr there as well , I'll call you later

dividing down 49152 pulses per inch travel by 2, brings us to 0.75 pulses every inch extra. So if I round that down to to 0 when a index event is counted I get a error of 0.000006 every inch, over 42.5 inches of travel "roughly speaking", I get a accumulated error of 5.5 thousandths from my g28 to x32 and back to g28 and this matches the exact behavior I am seeing.

This is a math problem in EMC2 motion control for sure. It is also a error I have observed on my mill with boring round holes. and other oddities. I did start looking over the code for positioning logic and there is yet ANOTHER issue with the 32b float format. there's only 6.92 decimal places possible for a 32bit float, meaning every 4 inches of travel I will EASILY exceed 100,000.0 pulses, this will ALSO accumulate a rounding error. Changing the code to 64bit will not fix the problem, simply kick the can further down the road.

also sharing the memory object across hal from encoder.c is foolish as well as it can create buffer over runs and memory leaks. I need time to think on how to fix this but my first inclination is to basically nuke the existing encoder logic and rewrite it entirely and remove the external calculation from the output and simply have ALL of the decoding and position logic moved into encoder.c as it should have been written from day 1. the other absolutely stupid thign that needs to be removed is the idea that you can accurately count the teeth 4x, this is just insane, the reason that the encoder works the way it does is because it is a binary switch, that's why the signals oppose each other. if you know the number of index pulses per revolution, and the pitch of the ball screw and the number of A and B pulses per revolution, and you do some simple math against a hardware clock you can easily ascertain with a very high degree of accuracy the rotational and linear position of the screw and predict where it will be using simple modeling tricks. In fact a kalman filter should be running in parallel as a error check against the current encoder decoding scheme to start with.

I'm going to go beat my head on the wall now while I figure out how to fix this

Much more likely this is an encoder hardware/setup  issue

Just verified HM2 encoder math  with 1000 PPR encoder,
(4000 counts per turn)

Verified against index signal, 500 turns out and 500 turns back
(500 turns is 2 million counts total)

Position is precise to the count at 500 and back at 0 again
as verified by index.

I have been hunting this now for several days. I still can find no apparent flaw in the encoder, no injected electrical noise , no lost teeth etc, no lash in the couplers, no lash in the ballscrew, no lash in the end support bearings, I can measure in the machine in any meaningful amount. if I push on the carriage with a 20 ton jack I get 0.0005 lash in Z axis lead screw where the error is occurring. I can also short run the Z axis lead screw with no obvious error accumulation IE 6 8 10 inches. However, I suspect the problem is a bit deeper. I can run the X axis back and forth along it's 12 inches of travel and it repeats to 0.00005 -+ every time but that is a much shorter travel path. The current encoder logic, it just count'sedges, and , this is patently the wrong way to use the encoder signals. there are 4 signal patterns on the encoder and they are all used to error check each other. you have AB 1 and AB0 and A1B0 and A0B1, these are all sine/cosine. The problem with the current method of counting, is that, it requires a perfect machine to work correctly by extrapolating tooth counts out 4x from the 4 tooth edges. What it doesn't do is any form of robust error checking to filter for noise in the mechanics of the machine or randomly miscounted teeth. at 76khz, which is 300ipm at 4096ppr, things are going to get difficult to count accurately over long distances if there is no noise handling in the code. There is currently no noise filtering comparison against the Z pulse ?index? there's no rationality check, If there were chronically undercounted teeth just doing a snap measurement every time the ABZ was true count = 4096, then you'd see the error immediately, the current code makes assumptions about a perfect machine that doesn't exist, it lack robust counting mechanism, counting edges is not the way the encoder is designed to work. it is a differential binary switch with 4 distinctly separate states, those states exist purely to ensure that there is a way to reduce noise. I'll be working on a new version of the encoder reading code and probably look at the firmware if it's available. at the Very least I am adding some sanity error checking to the encoder code, this is nuts. I also order a replacement encoder just to test with.  what's another $200 at this point. here is a gif that illustrates what I am saying about the encoders operation and why it is currently being done wrong
en.wikipedia.org/wiki/Incremental_encode...ectional_encoder.gif

Did you try enabling the encoder error detection as I mentioned?

The encoder A,B,Z inputs are all digitally filtered

Do you have the encoder filter bit set?

Also you can set the encoder  input filter bandwidth by changing the encoder sampling rate.
This may help when you have noise issues with single  ended encoder wiring.