Joint Error After large rotary move

Hi

when i am running a job and it incolves some 5 axis moves so C axis becomes quote a large count. as there is no unwind code i do a quick G10 L2 calc and run the next part

after running 5/6 parts i get a following error on C axis every time, if i rehome the joint (c axis) and G10 L20 to zero the joint error problems go awayi and i can carry on running parts untill the next 4/5 are done same joint error right at the same program point each time

ia this todo with some max count being reached?
what i have noticed is the raw count pin is counting right but the PID feedback is going from a - number jumping to a + number giving the joint error trigger,
-32767.84 to +32767.86
 

What version of LinuxCNC?

I don't recall any encoder bugs of that type, is it possible
there is a 32 bit wrap (that's a lot of turns though unless you
have a very high res encoder)

Also could be some kind of failing hardware (PC memory, PCI, FPGA card etc)

running version 2.9.2

reason for a high count on C is because its tool path with just continues +C axis moves in it to form a swarf move in a hole,

in the ini for the c axis i have
MIN_LIMIT = -1e99
MAX_LIMIT = 1e99

ENCODER_SCALE = 65536
#1/5 first gear , 1/72 worm 2nd gear
#16384*4= 65536 pp/r
#gears 1/5+1/72=1/360
#65536*360/360=65536

If you end up doing ~91 full turns (@65536 counts per degree and 360 degrees per turn)
the 32 bit signed position number used in intermediate encoder calculations will wrap, I suspect
this may be whats happening. Are 91 turns possible?

91 turns is possible very much so ,

this is just a simple small part so a complex job would very much be way over that turn number.

wrapping sounds right as number does a odd sign change in the feedback counts

Can you reduce the encoder scale? If not, probably best long term solution
would be for  the encoder driver to use 64 bit intermediate calculations.
I can take a look at this.

Would be grate to get a driver update to 64bit i have done the job so so rush for me, once done i can test it out
because as i see it even if i reduce for half on the count , will only give 180 turns, twise as many parts output.

Pushed a change to Master to use 64 bit integers for hm2 quadrature
encoder count values rather than 32 bit, Seems to work as expected.
(32 bit ints cause a wrap at  a count of 2147483648)

(looped back a stepgen at 30 M counts/sec to the encoder
input to test, still took a while...)