systematic drift on arcs

Hi Linux CNC forum, 

I'm building on a small CNC for over two years now. Unfortunately, I've been running in some issues while milling circular pockets.  
machine specs: 
Traj XYZA 
y-axis 1190 mm max travel, 20 mm ballscrew with 10 mm pitch, two 750W AC servo (HLTNC) 
x-axis 900 mm max travel, 20 mm ballscrew with 10 mm pitch, one 750W AC servo (HLTNC) 
z-axis 185 mm max travel, 16 mm ballscrew with 5 mm pitch, high torque nema 34 stepper 
spindle - 2,2 kw rattmotor air cooled
Brain of the operation: raspberry pi 4b+ using a parallel port hat and a 5 axis breakout board 
I'm running the premanufactured PI4 optimized Debian Bookworm image. 

Y-axis settings as follows: 
max_velocity = 5000 mm/min 
max_acc  = 20000 mm/min2
min limit = 0 mm
max limit = 1190 mm 
stepgen_maxaccel = 40000 
scale = 10 steps/mm -> (not sure why i set this to 10 -> 200 steps/rev and 10 mm pitch shall result in 20 steps/mm) 
FERROR = 1
Min_Ferror = 0.25

The issue: 
See attachment for further details 
arcs/circular shapes are for any reason shifted in XY - direction, the error occurs above 250 mm/min and is almost unchanged between 1000-5000 mm/min. 

What did i test up to now: 

1. Change base_period up and down -> the servos are set to 200 "steps"/rev, 10 mm pitch -> thus 20 steps/mm resulting in below 2000 pulses per second on one axis. Base_period is set to 100k, shall be fine? Changing the base_period to 40k didn't change anything as well as increasing the base period to 150k. 
2. Change max_acc to 4x max_velocity and stepgen to 2x max_acc -> didn't change anything 
3. check mechanical stiffness and backlash -> everything feels tight and rock solid, the linear guide rails are 20x30mm using very massiv long carriers. 
4. kill all unnecessary PIDs on the debain system in order to reduce latency -> didn't change anything

added the .hal and .ini file as attachments. 

Any hint or recommendation on how to improve this would be appreciated! 

Thank you!
Michael 








 

One guess is noise/crosstalk on the step/dir interface, especially if
the drives have a input capable of accepting high speed step signals.

Hi Peter,

thank you for your quick reply!

The step/puls signal wires are unshielded nearby the breakout board and stuffed into one cable collector. Puls signal level is 5V, max frequency at my current settings is 10khz for one axis.

I'll add some braided copper shielding to those wires and check if it helps.

Br
Michael

Adding a shield to the step cable has not changed anything.
I will scope the step signal in the next few days...
I tried it at least 8 times today at different speeds.... it was quite intriguing that the offset diameter increased when the speed was increased, but the offset angle always remained constant.


Anyone have any other recommendations on how to fix this?

Can you check if you have an accumulated error?
(does the spindle return to the same reference position when done)

losing steps on step space/time?

If you are not using reset mode (Not sure if the RPI can do this)
The step pulse width is the base period.

Drifting in a (mod) 45 degree angle suggests crosstalk to me.
Maybe a loose ground or 5V common in the step wiring?

If you are not loosing steps, like the spindle end up in a different position after you are done, I would guess something mechanical.
45 degree rotated ellipses reminds me of backlash.

did you tune your servos?
could be just small gain in drive.

Hi,
thanks to all for the suggestions!
did several checks today

1. start vs end positon -> 1.3 mm positive error on both axis -> accumulated error on both axis
2. checked step pulse width = base period 
3. mechanical test -> turned motors by hand while keep high resistance on the Z-axis plate -> everything feels rock solid with no observable backlash
4. tuning servos -> I use the T3D servodrive von HLTNC, did  several tests with different filter and timing values -> unchanged
5. something very strange did happen also today... by accident I run a testprogramm with 12.000 mm/min -> the circle was perfectly straight :O

still to do -> check electrical connections as Peter mentioned.