Auto_Bed_Leveling with positive Z_PROBE_OFFSET_FROM_EXTRUDER

[regpye]

And... Depending upon what happens when you bump that down to a 'reasonable' number... You may want to go to the very end of the run_z_probe() function and delete the code we added earlier.

//SERIAL_PROTOCOLLNPGM( "At end of run_z_probe() raising nozzle." );
do_blocking_move_relative( 0.0, 0.0, (float) Z_RAISE_BETWEEN_PROBINGS );
//SERIAL_PROTOCOLLNPGM( "At end of run_z_probe() done raising nozzle." );
} <---<<< Leave that brace in!

I think this is why we are getting the double lift. But be ready with your finger on the reset button if you take that line out!!!!

Looking at your Standard Deviation... Those numbers (.02) are a little bit on the big side. You should still get good prints, but you are getting close to an order of magnitude of your layer height. Oh! I just noticed you did the Z-Probe Standard Deviation both ways. The one that stresses the X & Y axis is concerning. .08 is getting too big in my opinion. The fact you get .02 without X & Y movement implies you have .05mm of slop in the X & Y axis. It is hard to say without the machine in front of me, but somehow moving the X & Y is adding .05mm of slop to the measurement ?????

On the bed topography. You have 1.5 mm or more slope from left to right. Can that be adjusted out on your design?

It's bed time for me. With a little luck, I'll get 9 hours of sleep tonight!

Yes I can easy make adjustments to manually level the bed better. Can there be some code that will assist in checking that easy, like measure each corner to see what difference there is?

I have taken out that line that you mentioned. Didn't see any difference when testing another print. The initial Z lift is close to 40mm I would guess.

[regpye]

Yes I can easy make adjustments to manually level the bed better. Can there be some code that will assist in checking that easy, like measure each corner to see what difference there is?

I have taken out that line that you mentioned. Didn't see any difference when testing another print. The initial Z lift is close to 40mm I would guess.

I have put that line back again. After removing it the bed leveling went haywire?? It didn't work properly for some reason. Tried it a couple of times and it was reading the levels wrong and the nozzle didn't come near the plate on one side and was touching on the other side. Put the line back and it is working again.
The initial lift is still about 40mm (guessing height)

[Roxy]

Yes I can easy make adjustments to manually level the bed better. Can there be some code that will assist in checking that easy, like measure each corner to see what difference there is?

That is one of the big benefits of the Bed Level Topology map. If you have the bed orientated the same way you have the #define's setup... You should be able to look at the topology map and picture that over your bed. If one corner is higher than the others, lower it and re-run the test. You will get a feel for how it zero's out. The biggest problem is if you correct one corner the right amount, the other corners sort of 'float' and it will be closer, but it won't be right. You keep getting closer and closer, but you never quite get there. And with a Standard Deviation of .02 for the Z-Probe measurements, you won't ever get it flatter than that. For the first couple of iterations, you can just use G29 n 2 T to get the readings quicker.

I have put that line back again. After removing it the bed leveling went haywire?? It didn't work properly for some reason. Tried it a couple of times and it was reading the levels wrong and the nozzle didn't come near the plate on one side and was touching on the other side. Put the line back and it is working again.
The initial lift is still about 40mm (guessing height)

OK. There is another place we can try. Or... If it is behaving rationally, we can just leave it. I was thinking a little bit more on the problem. The nozzle has to raise enough to have clearance, but it has to raise even more because your bed it tilted. If you measure a low spot, and raise it enough to have clearance, what happens if you move the nozzle to a high spot? You will scrape the nozzle. Raising it 4 or 5 mm above the bed might not be a bad thing to do in general.

And switching topics... I don't know which axis (X or Y) is the one that the nozzle is moving on. But if you do a set of M48 commands at both sides I bet you see a noticeably difference. My guess is doing an M48 x 25 y 25 n 10 v 4 is probably going to give a noticeably smaller Standard Deviation than doing a M48 x 175 y 175 n 10 v 4 If that is really true, the extra amount of error is coming in because the Z-Axis height is only set on the one side. My guess is adding the L 6 parameter to add legs of travel in X & Y might also show up on the far side. But if you do that, you have to be far enough away from the very edge that it can sweep out arcs. It won't go past the edge of your bed, but you will lose some of the legs of travel between moves if it tries to head off the bed.

Because of the design of the machine, there isn't really an easy way to improve that (if this assertion is true). But it is still worth while to know because what it will mean is you can print with higher accuracy closer to the Z-Axis support than on the far end of the X (or maybe it is Y) Axis.

[regpye]

That is one of the big benefits of the Bed Level Topology map. If you have the bed orientated the same way you have the #define's setup... You should be able to look at the topology map and picture that over your bed. If one corner is higher than the others, lower it and re-run the test. You will get a feel for how it zero's out. The biggest problem is if you correct one corner the right amount, the other corners sort of 'float' and it will be closer, but it won't be right. You keep getting closer and closer, but you never quite get there. And with a Standard Deviation of .02 for the Z-Probe measurements, you won't ever get it flatter than that. For the first couple of iterations, you can just use G29 n 2 T to get the readings quicker.




OK. There is another place we can try. Or... If it is behaving rationally, we can just leave it. I was thinking a little bit more on the problem. The nozzle has to raise enough to have clearance, but it has to raise even more because your bed it tilted. If you measure a low spot, and raise it enough to have clearance, what happens if you move the nozzle to a high spot? You will scrape the nozzle. Raising it 4 or 5 mm above the bed might not be a bad thing to do in general.

And switching topics... I don't know which axis (X or Y) is the one that the nozzle is moving on. But if you do a set of M48 commands at both sides I bet you see a noticeably difference. My guess is doing an M48 x 25 y 25 n 10 v 4 is probably going to give a noticeably smaller Standard Deviation than doing a M48 x 175 y 175 n 10 v 4 If that is really true, the extra amount of error is coming in because the Z-Axis height is only set on the one side. My guess is adding the L 6 parameter to add legs of travel in X & Y might also show up on the far side. But if you do that, you have to be far enough away from the very edge that it can sweep out arcs. It won't go past the edge of your bed, but you will lose some of the legs of travel between moves if it tries to head off the bed.

Because of the design of the machine, there isn't really an easy way to improve that (if this assertion is true). But it is still worth while to know because what it will mean is you can print with higher accuracy closer to the Z-Axis support than on the far end of the X (or maybe it is Y) Axis.

I have made a change to a line and now it is working pretty good.
// Keep this one. But delete the rest after it
do_blocking_move_relative( 0, 0, 5.0); // <---<<< for RegPye do_blocking_move_relative( 0, 0, 20.0);

The main problem now is not the coding, but the machine. There is too much flex on the right hand side of the bed plate. The nozzle is traveling on the X axis. The left hand side is fully supported by the bearings that are too close together and they need to be spaced further apart so that the floating end of the bed is supported. This is causing flex when doing the probing and although it doesn't seem to flex much, it will show up in the calculations. I guess I will need to design and build another one. Should be able to use the code as it is now, working well. Thanks for all your hard work.

[Roxy]

I have made a change to a line and now it is working pretty good.
// Keep this one. But delete the rest after it
do_blocking_move_relative( 0, 0, 5.0); // <---<<< for RegPye do_blocking_move_relative( 0, 0, 20.0);

Yeah... 20mm is excessive. But I didn't want to scrape the nozzle against the bed!

The main problem now is not the coding, but the machine. There is too much flex on the right hand side of the bed plate.

Did you actually get M48 numbers for both sides of the bed? You should see any flex show up as a bigger Standard Deviation of error in the measurements. On this kind of stuff, I like to have measurements before and after so I know if what I changed actually improved things. And if so... By how much.

The nozzle is traveling on the X axis. The left hand side is fully supported by the bearings that are too close together and they need to be spaced further apart so that the floating end of the bed is supported. This is causing flex when doing the probing and although it doesn't seem to flex much, it will show up in the calculations. I guess I will need to design and build another one. Should be able to use the code as it is now, working well. Thanks for all your hard work.

OK. Understood! Also, consider what happens if you print something heavy on that side of the bed. It will start warping just because the bed is being pushed down by the weight of the object being printed.

[regpye]

Did you actually get M48 numbers for both sides of the bed?
Yes it was giving numbers for both sides, no problem there.

OK. Understood! Also, consider what happens if you print something heavy on that side of the bed. It will start warping just because the bed is being pushed down by the weight of the object being printed.

Yes, I was bit concerned when I saw the original design and thought that it could be a problem. It turns out I was correct. Being as I have re-designed the whole machine so far. I will take it a bit further and re-design the layout better too, making the bed carriage wider and also more symmetrical. I can definitely see some flexing when the X is extended and the nozzle presses against the bed, there is too little support under the bed at that location. I have managed to get some good prints though. so a change or two can only make the machine better.

[Roxy]

Yes, I was bit concerned when I saw the original design and thought that it could be a problem. It turns out I was correct.
...
I can definitely see some flexing when the X is extended and the nozzle presses against the bed, there is too little support under the bed at that location. I have managed to get some good prints though. so a change or two can only make the machine better.

I've been thinking about this since I read it earlier today. The Bed Level Probing is different than normal printing. When you are printing you are going to have the issue of the weight of the nozzle and such flexing the support structure. But when you are probing, you get that error plus the error of pressing down on the bed.

This would be a horrible hack. But I wonder if putting in some kind of fudge factor depending upon how far out you are on the X-Axis would clean up the probing problem. And it wouldn't be that difficult to calibrate either. When you move the nozzle all the way out, you could visually see exactly when the nozzle just barely touched the bed. And then you could see how much the bed deflected before the probe detected it. That number is going to be different from what happens when you do the same thing without the X-Axis extended.

With those two numbers, it might be possible to 'scale' the numbers that are being generated during the G29. Because during a normal print, you don't want to be pressing down on things. You only have to deal with the 'normal' deflection. And if the above thoughts have merit and the G29 was 'corrected' to handle that... The routine bed leveling will handle the 'normal' case. Do you care to give that idea some thought and improve on it?

[regpye]

I've been thinking about this since I read it earlier today. The Bed Level Probing is different than normal printing. When you are printing you are going to have the issue of the weight of the nozzle and such flexing the support structure. But when you are probing, you get that error plus the error of pressing down on the bed.

This would be a horrible hack. But I wonder if putting in some kind of fudge factor depending upon how far out you are on the X-Axis would clean up the probing problem. And it wouldn't be that difficult to calibrate either. When you move the nozzle all the way out, you could visually see exactly when the nozzle just barely touched the bed. And then you could see how much the bed deflected before the probe detected it. That number is going to be different from what happens when you do the same thing without the X-Axis extended.

With those two numbers, it might be possible to 'scale' the numbers that are being generated during the G29. Because during a normal print, you don't want to be pressing down on things. You only have to deal with the 'normal' deflection. And if the above thoughts have merit and the G29 was 'corrected' to handle that... The routine bed leveling will handle the 'normal' case. Do you care to give that idea some thought and improve on it?

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 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.

[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)