Auto_Bed_Leveling: Z-Probe Repeatability code

[revwarguy]

The code base I am using has specific enhanemments other than M48/G29/G30 I need to use. My understanding is that it's g30 is better in that it takes only a few passes to converge, so I was also hoping to use it.

Thanks for the help, Roxy. I guess I'll just have to work it out what is going on with what I have.

I sure would like to know why they rewrote your m48 code for the latest Marlin pull, though. As it is, there is a lot of code in marlin_main.cpp for this stuff when it seems it could be unified into something much simpler.

[revwarguy]

Ok, give me a bit to get the Zalm configuration.h updated to my machine. Other than that, the M48, G29, G30 and relavant section of the configuration.h file appears to be the same as what I am running on my verison, with the exception I mentioned before - I've cut off the engage_z_probe() and retract_z_probe() routines to just return right away as I don't need to do that. Could there be something in there that is needed later that is the problem?

You know who PJR is?

[Roxy]

Ok, give me a bit to get the Zalm configuration.h updated to my machine. Other than that, the M48, G29, G30 and relavant section of the configuration.h file appears to be the same as what I am running on my verison, with the exception I mentioned before - I've cut off the engage_z_probe() and retract_z_probe() routines to just return right away as I don't need to do that. Could there be something in there that is needed later that is the problem?

I think what you ought to do is leave the engage_z_probe() and retract_z_probe() alone and just assign them to use unused pins. That way everything is behaving the same other than those two functions don't do anything. But with that said, making them null routines really ought to be OK.

Part of the reason to leave the engage_z_probe() and retract_z_probe() alone is there may be other code that assumes a servo is available because you have Auto Bed Leveling. That would be the easiest path to getting everything going. And then when everything is working we can prune the servo out of the picture.

You know who PJR is?

No...

[brucehvn]

Roxy, I've got a question about how the z position numbers are calculated in your M48 code compared to other commands. I've been battling a problem all day that started with a wire falling off my z-probe. After fixing that, I noticed that the microswitch was slightly tilted and when coming down to the bed, the lever would hit first, but before tripping, the opposite side of the switch would hit the glass and move the arm slightly. I adjusted that and since I haven't been able to get a good print. I've gone around and around adjusting the z probe offset value and storing it in EEPROM, but every time I try to start a print, it's just smashing the filament down on the glass making blobs and wide streaks.

Anyway, what I've noticed is that if my current offset is set to say -10.65, when I run the G29 command, the 4 points it probes list z values close to and around that offset. However, when I run the M48 code, the numbers it reports for each sample are around the 10.24 range. The test comes out very acceptable. I can't see that there's any great fluctuation or problems with the probe, but I'm curious why the numbers are different as that amount of difference looks to be in the ballpark of what might actually get it printing properly again. I'd guess it's about .4mm off.

Bruce

[MichaelBrock]

Anyway, what I've noticed is that if my current offset is set to say -10.65, when I run the G29 command, the 4 points it probes list z values close to and around that offset. However, when I run the M48 code, the numbers it reports for each sample are around the 10.24 range. The test comes out very acceptable. I can't see that there's any great fluctuation or problems with the probe, but I'm curious why the numbers are different as that amount of difference looks to be in the ballpark of what might actually get it printing properly again. I'd guess it's about .4mm off.

Bruce

Bruce,

Did you figure this out? I'm having the same issue. G29 results seem to vary quite a bit but M48 results are very consistent and differ from the G29 resutls. And, like you, the difference seems like it would explain my occassional air prints. It seems the two should produce similar measurements. If not, it would be nice to have an explanation as to why.

[Roxy]

I'm sorry... I didn't see Bruce's question until just now.

The answer is: "Don't worry about it." The root of the problem is the different GCode commands use different methods to probe the bed. That is slowly getting unified. But because they use different methods, they report some what different values. G28 does its thing using linear move routines. G29 uses the probe_pt() routine and then corrects for Z_PROBE_OFFSET_FROM_EXTRUDER. And M48 is sort of a hybrid of the two.

This is getting corrected, but right now getting the Release Candidate stable and out the door is a higher priority.

If you use G29, don't worry about the G28 numbers. G29 is correcting for the bigger picture. G28 is mostly concerned about making sure the nozzle is within the build space.

And M48 doesn't care about any of that. It just cares that it can accurately measure the location of the probe again and again. It subtracts off what ever the mean of the measured points is and calculates the standard deviation.

[htaxil]

Hi Roxy,

It's with great interest that I readed this thread of discuss, and I thank you for the great job and the support you provide.

I constructed a Delta printer with a probe for the Bed Auto Leveling incorporated into the effector, so that the HotEnd's nozzle is the probe. I would be interested in your M48 function, but from what I've read, your code was integrated into the Marlin firmware, but no longer works well since the great upheaval this summer ...

My questions :
- Does the Z_MIN_PROBE_REPEATABILITY_TEST function has to do with your M48 function? If so, how can we setup number of measuring ... ?
- I also read that the M48 function was not available for the Delta because of the gap between the probe and the nozzle could generate impossible calculations (sqtr(zero)). Since in my case the nozzle is the probe, could i override and how?
- last question: G29 function seems to work fine, however the recorded data do not seem to be taken into account when printing. I saw that I was not alone having this problem, but I did not see any solution except to upgrade to Marlin RC3 version ... but I'm already in the RC3 version ... An idea?

Best regards,
Hubert

[Roxy]

Hi Roxy,

My questions :
- Does the Z_MIN_PROBE_REPEATABILITY_TEST function has to do with your M48 function? If so, how can we setup number of measuring ... ?
- I also read that the M48 function was not available for the Delta because of the gap between the probe and the nozzle could generate impossible calculations (sqtr(zero)). Since in my case the nozzle is the probe, could i override and how?
- last question: G29 function seems to work fine, however the recorded data do not seem to be taken into account when printing. I saw that I was not alone having this problem, but I did not see any solution except to upgrade to Marlin RC3 version ... but I'm already in the RC3 version ... An idea?

1) Yes. That controls the ability to do M48 and test how repeatable the Z-Probe is. But the Release Candidates do not support M48 for Deltas.

2) Yes. I did not have a Delta when I wrote the M48 code. I didn't know they use different routines to move the effector. The sqrt() of a negative number is related to trying to move the nozzle off the bed so you can probe the maximum area. Don't worry about that right now.

3) The M48 code is working for Delta's now. But you have to go to the MarlinDev side of the fence and bring up WackerBarth's new development environment. (That is what we expect the Marlin Development Team will be switching too.) You can find it here: https://github.com/Wackerbarth/MarlinDev/tree/Dec26 Look at the Wiki for the complete directions how to get the environment set up. This branch has a lot of Delta stuff fixed. But we are trying to get the Release Candidate to the state it needs to be without adding any thing that doesn't have to be in it.

[htaxil]

Hi Roxy,

I took your advice and installed the MarlinDev environment. It works correctly, I can compile with no problem at all.
However, I am a bit confused because this version of the firmware adopts a new method of statement of parameters that the wiki does not explain (https://github.com/MarlinFirmware/Ma...Configurations)

According to what I read, good practices are to define a file of parameters for every type of printer, and to decline sub-configurations for every machine by using the mechanism of inheritance.

My question: Is there a documentation, even has the state of draft somewhere? If not, can you tell me what are the new files of configuration to use (customization.h, FirmwareCustomization.h...) and how to integrate them into the firmware?

Best regards,
Hubert

[Roxy]

Richard Wackerbarth is doing the work on this branch. It is my expectation that after we do the next release this will be used as the next official MarlinDev environment with the intention that it will be promoted to Release Candidate status. (Mostly, I'm just trying to say, this isn't wasted effort on your part.)

My suggestion is go to https://github.com/MarlinFirmware/Ma...3Aupdated-desc and start a thread asking for assistance. Please be sure to explain why you are trying to use the branch and that you were requested to use it and ask for assistance at MarlinDev. The problem is I'm just starting to get my head around the new organization myself. I'll help you with what I can, but the changes that it takes to clean up the code are extensive. You will get better and quicker help at MarlinDev.