This has me baffled. The Y is correct, the X is short by about 1%.
Thing is, these are set by timing pulley tooth ratios. It can’t gradually change. The only way the travel per step changes in any way is to change the tooth count on pullies.
Large backlash problems will manifest as being “short” when you change directions, which would be similar. But there’s no evidence of backlash on this magnitude- bidirectional rastering will be totally wrecked as the leftgoing and rightgoing lines won’t match up at all. That’s not happening. Any kind of slack or slipping or “lost steps” is going to cause more noticeable effects in other areas and that’s not happening. I went looking for any place where a backlash compensation could be set because that compensation, if inaccurate, will create the same sort of error.
The config has the correct value for travel per step, I pulled up older config files that get burned onto the Ruida and they don’t perform any differently. I temporarily linked Dorian’s LB installation to access Tarkin to send a job from a different install of LB, the prob is still there.
In the end I just reduced the configured travel per step in the config by 1%, and its X axis cuts measure up correctly. That’s restoring its accuracy overall, so it should be fine for the user- it’s not the right way to do it, but I just don’t see what is causing it.