Quote Originally Posted by regpye View Post
I had been thinking about the very same thing a while back, but I have no idea of how to implement it. There are a number of machines already made that this would be very useful for.
My idea is to get the machine right so that there is no need for it, however many people will still have the issues that we have discovered.
Is there some way that this fudge factor can be turned on or off so that the code can be used for a machine that needs fudge and one that does not?
I do not think this is very difficult to do. There would be a couple of approaches. Probably the simplest and most straight forward method would be to modify the run_z_probe() function to return values that were compensated. These values would bubble up to the G29 code that is collecting them and the Bed_Level_Correction_Matrix that is needed for the rest of the moves would have this factor built into it.

It would not be difficult to make it selectable on either of two basis. It could be made so it was optional for a machine and gets built into the firmware with a #define in the configuration.h file. It would also be very straight forward to add a parameter to the G29 command to build the Bed_Level_Correction_Matrix with this factored in.

Assuming the firmware existed, the process of setting up a printer to use this would not be hard. It would involve taking a measurement on one side and comparing it to when you manually adjusted the nozzle to just barely touch the bed. And then repeating it on the other side of the bed.

Quote Originally Posted by regpye View Post
I have re-designed a new Y plate and it has almost finished printing. It means a total re-build of the machine so I guess it is easier to build yet another machine and leave all the others intact.
Hey! I have an idea... Would it make sense to get one machine all the way working before you ramp production?