Using the Z probe to set bed hight rather than just bed level

I found that in the Snapmaker 2 controller GitHub - Snapmaker/Snapmaker2-Controller: Snapmaker2-Controller is the firmware for Snapmaker 2.0 3-in-1 3D Printers. software there is a function to turn off bed heating on entering the G1029A function. It’s line 111 of G1029.cpp.

//thermalManager.disable_all_heaters();

Now my bed stays hot through the full calibration cycle. Remember to turn off the heater with M190 S0 and M104 S0 at the end.

I did check the values the probe was reading and it seems stable not affected by the bed being heated.

NOTE: CHANGING THE FIRMWARE AT YOUR OWN RISK - VOIDS YOUR WARRANTY

If you don’t change G1029.cpp the gcode below still works but the bed cools as it is being probed.

====== (Here is my Auto level code) =====

M1010 S3 P100; LED On
G1029P11 ;Grid 11x11 Change the P value for P3 for 3x3 or P5 for 5xt etc

G0 X0 Y300 Z300 F60000 ; Rapid before G1029 to save time

M104 S205; Set Nozel Temp
M190 S70; Set Bed Temp
G1029A ; Bed Level

;Set Nozzle height
G91
G1 Z-1.87; Bigger number closer to bed
M400 ;Wait for Z offset to finish
G90

;Save Setting
G1029S
G1029D0
M420V
M851
M104 S0 ;Extruder heater off
M140 S0 ;Bed off
G28; Home

2 Likes

I have read many times that ppl tells to wait before calibration.
But this only is good if you do the same for the first print, then keep printing.
Otherwise your first print (when you turn on the machine) will heat up the bed and then start printing before the bed settles and matches the calibration data.
I don’t like the idea of waiting 30 minutes for my first print…

@theenginerdinglab, great, if I ever pluck up the courage to to mess with the firmware I will certainly do this. From lots of other posts I did think they were going to remove the bed and nozzle power off within bed leveling within the default firmware but I am still waiting.

@ctaddey, agree the wait is a pain but I always have another 20 things I have not done and the benefit of this approach is it’s fire and forget. My workflow all runs from my favourite chair in front of the TV/Music, I set heat and nozzle temp in Octoprint, sort out what I am printing in Prusa or Cura (depending on what the job is), when sorted I hit send to Octoprint and everything happens automatically without me getting out of my chair. It might take 15 minutes longer but none of thats wasted waiting by the machine time, I am in my chair working on the other 20 things I never catch up on. Might not work for everybody - you just need to sort out your preferred method and this is just a different option.

1 Like

@stewl Thanks for this. I am new to OctoPrint and was having difficult setting my z-offset. The first few times I tried to print, filament was being extruded into thin air.

Also great idea on the conditional statement based on profile name. I noticed that the string for the the profile name got wrapped in smart quotes (“Snap3DPrintLevel”)

Below is your gcode marked up with

;bed level and Z offsite profile with profile selection to just print
{% if printer_profile.name == "Snap3DPrintLevel" %}
G21 ; set units to millimetres
G90 ; use absolute positioning
; start heaters for bed level
M140 S65 ; set bed temp
G28 ;home
M190 S65 ; wait for bed temp
;Auto Level
G1029 A ;start levelling
G91; relative positioning for Z offset move
;*****************
G0 Z-2.05; Device specific Z offset, reduce to bring print closer to the bed. (equivalent to M851)
;*****************
G1029 S ;save data
G1029 D0 ;end levelling
G0 Z10; move up 10mm
G90; restore absolute positioning
{% else %}
G28 ;home to match levelling script
{% endif %}

Thanks @chemist, didn’t notice that, good of you to fix it but how did you manage it?
Tried to post my current profile with out smart quotes and it keeps changing them.

I wrapped the gcode in code markup using the formatting menu… bold, italic, link, quote, code… That should prevent automagical creation of "smart" quotes.

Addressing the comments from @brent113 should be doable with an or statement and a nested if, but I’m not familiar enough with gcode to get that to work.

I thought this would work, but the printer can’t parse this line at all and skips the entire if statement

{% if printer_profile.name == "FastAutoLevel"%} || {% if printer_profile.name == "SlowAutoLevel"%}

Then after the wait for the bed to warm up, a nested if could pause the printer for e.g., 30 minutes so that the bed equilibrates and further deformation is minimal

; dwell at temperature for 30 minutes to allow bed to equilibrate
{% if printer_profile.name == "SlowAutoLevel" %}G4 S1800

Then proceed with the autolevel. Of course the code could just be copied and pasted with another if or an elseif

If the base layer will be laid down relatively quickly in the center of the bed using the profile to “just print” without autoleveling, then calibration data based off an equilibrated bed might not best represent it’s shape because the bed will not had time to fully distort.

Heating the nozzle is recommended in the info I read on the Marlin site, the print head module should be at operating temperature warming up the sensor and mounts won’t hurt anyway.

Seems a waste to do this each time as the calibration mesh and the offset are saved, you don’t need to recalibrate unless you change the machine function or do you just use this button when you need to?

I agree, I had two profiles and only used this if I wanted to level. I now have the code in a macro in OctoPrint using the Macro plugin and run the macro when something has changed. The main point is it removes that final human level at the end of calibration. This is unnecessary as the distance between the sensor and the nozzle does not change so the macro replaces that manual step and allows you to dial in the nozzle height consistently.
It’s now got a whole lot more accurate as I print on glass and have changed the sensor out for an IR one that levels on glass and I am getting much more accurate leveling than with the original sensor and bed.

The macro I use is in the instructions for changing the sensor.
https://drive.google.com/drive/folders/1JTZ811Tx-dTD35J4a-u2fsokln20INpR?usp=sharing

@theenginerdinglab Since I wanted to change the firmware to adjust the sensor offset for my new IR sensor I thought I would fix the G1029 command switching off the bed and nozzle heat. I found the line you identified commented it out and built and packed the code per instructions on GitHub. I got a few warnings but no errors. I uploaded the major image to the Snapmaker which reported success. When I run G1029 though all the heaters still switch off. Does commenting out the line in G1029.cpp still work for you?

Yes commenting out the line in G1029.cpp works for me. I just did a bed calibration this morning with the heaters on through the full calibration. (I did a manual calibration this time) But still, bed did not turn off. I guess you need to be certain the new firmware did get flashed into the A350. May be it did not flash and you still running stock A350 code.

Says it’s running FIRMWARE_NAME:Marlin SM2-4.2.2 (Github) which is what I flashed it as.
This is my line 111 in G1029.cpp

const bool seen_a = parser.seen(“A”);
if (seen_a) {
// stewl comment out line below to stop switching off heaters at start of G1029 bed level
// thermalManager.disable_all_heaters();
process_cmd_imd(“G28”);
set_bed_leveling_enabled(false);

Re-boot and G029 bed level includes
Send: G1029 A
Recv: new E target temp: 0
Recv: new B target temp: 0
Recv: new E target temp: 0

Must be doing the build process wrong somehow.

I have forwarded this post to our R&D team and they are very interested in it. If you need any help from the firmware developer team, please pull a request on the GitHub page.

Here is the link:
https://github.com/Snapmaker/Snapmaker2-Controller/pulls

Cheers
Edwin

1 Like

I have put a question on GitHub, not up on pulls, never used GitHub before. Anybody on the forum know why changed firmware doesn’t make the expected alterations in the printer behaviour?
I think it’s just the G1029.cpp file change that is not updating. Do I need a C++ compiler in addition to PlatformIO?

Last question
My sensor offset is X13.5 Y0. The stock numbers are X13 Y19.15. If I do a G30 probe the response is:-
Send: G30 X200 Y200
Move to X: 186.50, Y: 200.00, Z: 10.79
This equates to my revised Z offset.
However I then get
Bed X: 200.00 Y: 200.00 Z: 10.77
Fine, telling me it’s really X200, Y200
But then I get the following
X:167.50 Y:190.00 Z:10.77 E:0.00 Count X:74600 Y:80000 Z:4308 B:0
What’s this about? A M114 also gives
X:167.50 Y:190.00 Z:10.77 E:0.00 Count X:74600 Y:80000 Z:4308 B:0
Also if I do G1 X200 Y200 and then G30 X200 Y200 I would expect the X-axis to move 13.5mm and the Y-axis to stay still but they both move.
Do I need to change anything in addition to the numbers in line 868 of configuration.h

You have to change the version number and then pack, the controller will ignore firmwares with the same version number. Try “SM2-4.2.2b”

The pack process finds that string via a regex and puts it in the firmware package: Snapmaker2-Controller/pack.py at c09a114cfef9892fe7d2b4aa5b56531ffc828a8d · Snapmaker/Snapmaker2-Controller · GitHub

Thank you Brent I would never have though of that version SM2-4.2.2b now working fine. I have been messing about with this for ages, even tried building on another machine. It all makes sense now. I did a build to change the probe offset then another to stop the heaters switching off which was ignored as it had the same version number. Shame the console and the log tell you the upgrade was successful.
Out of interest do you know what’s going on with the positioning and Probe offset or am I worrying unnecessarily.
@Edwin, would be handy to have this in the build instructions on GitHub. I have updated my issue on GitHub with a relevant comment and closed it.

1 Like

I’m not 100% sure what you’re talking about. Reading the 2nd half of your above post I don’t really know what to make of it. I haven’t spend long enough with G30s to get a sense of what to expect for positioning ‘under the hood’. Does seem like something is wrong though.

Yea, 100% agree. That caught me off guard a few times. Would be a great pull request.

I think I am just worried that there are still bits in the bed leveling that dont make complete sense.
In standard Marlin you specify the difference between the position of the nozzle and probe. The leveling software uses that offset to probe the bed with the sensor in the place the nozzle would be using the X & Y coordinates.
In my example I do a G30 probe of X200 Y200 and the head is moved to X186.5 Y200 as that puts the probe over X200 Y200 as my offset is X13.5 Y0. When I send the command it correctly reports a move to X186.5 Y200, all looking good.
After the probe which only involves Z axis movement the position is reported as X167.5 Y190.0. No idea where this number comes from. If I issue an M114 it confirms the head position as X167.5 Y190. That is completely wrong.
As a sanity check I set absolute positioning, did a G1 X200 Y200 and then did a G30 X200 Y200. As my sensor Y offset is zero I should see an X axis move and no Y axis move as the head goes to X186.5 Y200 but thats not what happens, the head actually moves in both X and Y to X167.5 Y190.0. The code is probing the bed in the wrong place. I just dont know why but wonder whether it’s something that might be impacting all the leveling that people are having so much trouble with or is there another set of offsets that I also need to adjust.

I wonder if this is a new bug. I don’t recall ever hearing about this in older firmware.

I will go back to the stock 1.12.1 firmware and check whether the G30 move position differs from a report of the actual position. If it does then I think there is a software issue. If it’s right there is something else I will need to change to set the correct probe offset.

1 Like