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

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
image missing https://en.wikipedia.org/wiki/Incremental_encoder#/media/File:Incremental_directional_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.

This sounds like a noise issue to me. I would suggest trying clamp-on ferrite beads on the encoder cables.

The encoder frequencies are really low and should not be a problem for hardware decoding. Software decoding would probably have issues though.

I don't get your complaint about the quadrature decoding. The 4x decoding is very standard and you can still do error detection with a state machine that flags illegal transitions. Limiting yourself to 1 count/line will not improve noise immunity and just reduces your effective resolution. Encoder inputs should be error free and this is quite achievable with the noise margins in the system. An error rate of better than 10^-12 (or one every 100days at 100kHz encoder rate) is easily achievable. Realistically the error floor is more likely to be around 10^-15 and effectively zero.

My mill has 25400 counts/inch and at 600ipm and 30" of travel I have seen zero lost counts. The machine has been running for over a year now with no problems with repeatability. This has been checked with a renishaw probe system and the machine will repeat to the um when probing.

it's not a noise problem. But I will give everyone a hint. 6.92  you'll figure it out eventually. Now I have to get back to debugging my complete rewrite of encoder.c sorry, uploaded older version with broken Z output. on another note, this has got to be the worst forum software I have ever used. god this is awful.

my encoders generate 49152 pulse per inch. i don't have a problem with quadratic counting, i have a problem with how that is being handled currently