problems with Y-Axis, elliptic deviations after several changes -Probe Basic V.5

Thanks for your answer! My tests are in aluminum EN-AW 5083. That is my target material.
Yes I know that a really stiff machine should be made of steel or cast, but I have bult what I could.

Ok 500 is fine. I knew it is 1000 for 1 ms but not how it scaled.
I was looking for a reason for the following error.
Since the feedback comes from the step generator and not the actual machine,
it seems to me the step generator is to blame.
You get following error even when running in air, right?
Basically linuxcnc, or perhaps the step generator, generates the wrong tool path in Y.
Unfottunately I don't know how to fix it.
 

Thanks, Hakan. Yes, yesterday I cancelled my Air-path as I could see the motor is going into alarm. I don't know if there is a following error as a reason for this, Iwill pot my serial connection to the motor today to read the logs and reproduce the error.

What I can say, mechanics are not the reason, because - what I changed just before were the entries at FERROR and MIN.FERROR to 0.1 and 0.01, exactly what is in the x-axis, which is running fine with these settings.

are getting reported when from driver's or linuxcnc? What is the axis drive type? Bal screws or rack or belt? Edit: Nevermind saw c5 screws 

Your fixed bearing arrangement isn't ideal. Ac bearings should be matched sets requiring no intermediary spacers for preload.  Adjusting correct preload with spacers between the bearing set is incredibly variable and difficult.  It is for certain an easy way to destroy bearings as I've done it in the past and turned the balls to crumbled bits.  That said I don't think that's enough for your deviation, just a suggestion for future improvement. 

Feed forward is used with PID tuning for servos and a feed back loop, if your using simple steppers this shouldn't need an adjustment over the ff = 1

 

Are you dropping packets? that is, what is:

hm2_7i76e.0.packet-error-total

A dropped packet will result in a (bogus) following error spike,
as stale stepgen position (from the previous cycle) will be compared
with the commanded position. At a 2 ms servo thread period and 125 mm/sec
velocity, a .25 mm reported following error value is possible from a dropped
packet. Note the this does not mean that there is an actual path deviation
of this magnitude, this is bounded by the max_error PID pin to ~.0127 mm
per dropped packet.

I still think the physical error is most likely mechanical as it only shows up on Y.

To diagnose stepgen errors, the best thing is to plot the following error
with halscope like this:

 


Note that this is in inches, but the velocity and acceleration are about 4x and 6X your machines values
and the inherent stepgen error is less than  0.25 micron.

Another possibility if the system latency is really bad, is loss of DPLL sync, so you might try increasing
the DPLL time from -250 to -500 usec

 

Also are those things correct for your steppers, they look big to me.