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

25 Jan 2023 23:51 #262913 by ZincBoy
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.

Please Log in or Create an account to join the conversation.

29 Jan 2023 01:26 - 29 Jan 2023 19:17 #263145 by smc.collins
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 
Last edit: 29 Jan 2023 19:17 by smc.collins.

Please Log in or Create an account to join the conversation.

31 Jan 2023 03:51 #263294 by smc.collins
engineering.purdue.edu/~dionysis/EE452/L...er_Guide_sprufk8.pdf Absolutely required reading, and I have been running encoder simulations and looking over the code, it is very possible in some edge circumstances that clock alignment at high frequency's might be causing a loss of pulses or a buffer overflow in certain conditions. I have seen counting errors at very high count rates and small off periods over extended periods of time, we are talking 1,000,000 or more pulses, which is in the range of where I see trouble.

Please Log in or Create an account to join the conversation.

02 Feb 2023 23:49 #263556 by andypugh

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,

But: LinuxCNC uses 64-bit doubles throughout. 

And, more importantly, it doesn't actually use the float to store position. The accumulated encoder counts are stored in a 64 bit accumulator and then the (float) position is calculated from that every time. 

I don't think that there is any scope for rounding errors in this way of doing things. 

Please Log in or Create an account to join the conversation.

Time to create page: 0.499 seconds
Powered by Kunena Forum