Auto_Bed_Leveling with positive Z_PROBE_OFFSET_FROM_EXTRUDER

[Roxy]

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.

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?

[regpye]

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.



Hey! I have an idea... Would it make sense to get one machine all the way working before you ramp production?

Sounds like you can do it.
I have the new design already printed and I have started to assemble, however I have to go to the city again today, so the whole day will be lost, it will be late when I get back and after driving for about 8 hours I will be too tired to do anything. (but sleep)
Having a few different machines will be a good thing because we can test all sorts of configurations and code changes. I wish I had followed my gut feeling in the beginning and made this latest change to the hardware from the beginning. At least it will be a better machine as the end result, worth it I feel to spend the time and money now in development. (Anyway, it is fun)

I have about 6 already built that could use the new code and about 18 sets of parts that have been printed that if built could use the new code. There are plenty of people out there that have their own version of this machine and will be facing the same problems as they were all based on the original design that fist came out using a servo (that model also suffered from the same problem, but not as much)

[regpye]

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.



Hey! I have an idea... Would it make sense to get one machine all the way working before you ramp production?

I have shared the Marlin that we are working on with a few guys that also have a very similar machine on the SmartRap forum.
They are testing it too. Their machines are also the same configuration of the hardware.
One of the guys is having a few issues, but I think the problem could be that he has an open z probe caused by the Bowden weight holding the probing mechanism to one side. I had that happen to me once and recognized the same problems that he is having.

http://forums.reprap.org/read.php?34...614#msg-356614