This discussion is continuing on GitHub.
If any of you coders have time to have a look at what Snapmaker say that would be great, I am struggling with the code. They think it’s all fine, actual practical tests suggest it’s not.
As an aside, I Also had a PM from Edwin and he is leaving the company. That will be a loss as he has been very helpful on this forum. I do hope they allocate a replacement to monitor it and help users. It’s a much better support tool than Facebook.
Thank you for mentioning me here. I have pleased @scotthuang and @parachvte to answer this post. It is a great pleasure that having you guys in firmware development and software development. We value all the advices and issues you raised.
We will have another support staff here to offer the help continuously.
Tons of thanks to all users here.
Edwin
Do we think this will make it into the next firmware update? I’ve been fighting bed level and have been doing in manually since the beginning. My 350 is basically a 200 at he moment.
Not even admitted as a problem yet. It’s now an ongoing discussion on GitHub. Best watch there to see how it turns out.
I’ll see if I can take a look at it.
@parachvte and @scotthsl have given a good explanation of how Snapmaker does the G1029 bed levelling. I almost managed to understand it. The missing bit is how this aligns with printing. They are looking at my practical example now I hope, if they get the same result I am sure they will sort out what is going on. They have the right people looking at this @scotthsl is shown as a contributor to most of their Controller code changes.
I think Snapmaker records the probe level as at the Raw coordinates of the matrix they calculate but that calculated matrix includes the offset. The print routine treats the matrix locations as if it were calculated using the standard G29 methodology which aligns with G42 locations. I could be well wrong though!
Answer received. The bed levelling process and levelling when printing are not aligned, they are out by X19 Y10.
Snapmaker are going to fix it “as soon as possible”. Details in GitHub issue #113 as in the link above.
Just have to wait and see how fast it comes out.
And if it’s corrected without causing other issues, as is the reputation of Snapmaker’s firmware updates lol
@stewl what do you envision the resulting behavior should be for the following gcode sequence
G90 ; Abs. mode
G1 X100 Y100 Z50 ; Move to location
G30 ; 1) What happens here movement-wise
; 2) Where is the toolhead now
When the G30 is issued, would you expect the toolhead to jog to the side by the probe offset? I believe that is not happening now, but should, right? Said another way, the toolhead moves in both X, Y, and then Z when the G30 is issued, and not just Z?
After the probe is complete, where is the toolhead left - at the probe location or would it automatically jog back to the pre-measurement location? That is, undoing any X/Y move from 1. above
This will be something to follow up on, and to @Artezio’s point, ensure it’s implemented correctly as any such unit testing for this functionality clearly is absent.
This does not just involve probe offset it also involves workspace offset so I better start with a definition for this discussion - even if it’s not super correct. RAW coordinates are the measured coordinates from the X & Y end stops. Snapmaker does printing in a workspace offset of X-19 Y-10. So when you do a G1 X100 Y100 the nozzle moves to a logical X100 Y100 which is the RAW position of X81 Y90. My probe is offset from the nozzle by X13.5 Y0. I am going to stick with those numbers as the Y0 makes counting easy 
. In the above example when the nozzle is moved to logical X100 Y100 the probe will be at logical X113.5 Y100, RAW X94.5 Y90.
As of now, G30 just does a Z probe of the current position. It doesn’t move in the X or Y direction to handle probe offset or anything else. That’s not what it reports it’s doing however.
Your example of G1 X100 Y100 followed by a G30 the nozzle moves to the logical position X100 Y100 G30 probes the bed without XY movement and reports:-
“ProbeX:132.50 ProbeY:110.00Avtive:1”
“Move to X: 119.00, Y: 110.00”
So it’s assuming the current position is RAW nozzle X100 Y100 reporting logical X119 Y110 with the probe at position X132.5 Y110. Thats a wrong assumption.
My reading of the limited Marlin documentation says G30 probes the current position so I dont think it should move for the probe offset but it should report the correct numbers - this is different from the RepRap G30 behaviour.
It gets a bit more interesting with a G30 X100 Y100
In this case it reports that it will:-
“ProbeX:100.00 ProbeY:100.00Avtive:1”
“Move to X: 86.50, Y: 100.00”
That all looks good, do a move to put the probe over X100, Y100 - but it’s not what it does.
It actually moves the Nozzle to logical X67.5 Y90. Thats what the RAW coordinates would be if it was putting the nozzle into position to probe logical X100 Y100 but it’s done it within the logical workspace so it’s effectively probing the RAW position rather than the logical one. This is the same problem that there is with bed leveling.
My understanding is that a G30 without parameters should do a probe without moving the head. The behaviour is correct but the position reporting is wrong and needs fixing.
A G30 with X & Y parameters has the same issue as bed leveling and probes the wrong point, effectively double counting the workspace offset. It would be good if the bed levelling changes also fix this.
Does this equate with your understanding @brent113? If it does I will add a comment to the GitHub issue asking them to make sure this is also fixed and ask whether a new issue is required.
My main concern though is bed levelling and I want that fixed fast but I would like to see it done so that levelling follows the standard Marling G29 code as much as possible and hopefully it will also sort out issues like this.
I see G30 as a simple way of verifying bed leveling as under the hood they use the same library functions.
Your explanation sounds reasonable but I don’t have a deep enough understanding yet to confirm.
If all you want to do is compare the level across the bed using G30, as long as you specify where you want the nozzle to be then move X, Y to that point followed by G30 it will work fine.
If you want to compare a G30 value with an existing level to see if it’s still correct it’s not that simple!
I started my checking after I replaced the sensor with comparison of the leveling values with G30 Z values and could not work out what was going on. Part of it was the miss match in the levelling but thats not all.
If you do a bed level, look at each reported Z height, take off the Z offset you measured by lowering the nozzle after the last point and then compare this with the M420V level you will find that it’s 1mm higher than the M420V number. Where this 1mm comes from I just don’t know. It’s not M851 which does report 1mm as changing this number changes nothing. It’s not the number in configuration.h for Z probe offset, the default is 1mm but the firmware I am running has 2.61mm here.
In addition, when I do a number of bed levels as long as the bed stays at a constant temp, every point changes less than 0.02mm different over multiple runs, the vast majority are less that 0.01mm . If after a bed level I move the sensor to the same position as one of the leveling points and do a G30, take of the Z offset plus the phantom 1mm, the value is 0.05mm different from the level height. Now it’s not much but it’s a material number. Not only that but it’s consistent. Do the level again and the G30 point probe and it’s about .005mm out ± 0.01mm. I even tried it with a jog round a square before the G30 and it’s just the same. I have no idea what is going on but it does make G30 less useful.
All suggestions welcome
In the mean time can we set the M206 x 0 y 0 z 0 to compensate?
Thanks
Caleb
No, that will move the center of the bed as far as the machine is concerned, while also not appropriately compensating for the probe offset.
ok bummer but thanks. I have crazy issues with bed leveling
at the moment can’t get anything to stick, and if it does stick and print well, it gets really bubbly as it moves across the bed as the nozzle gets to close to the bed.
and then as it moves in Y it will get way to high and not stick then gum up my nozzle. really don’t know what happened but my bed is way off now
Recv: 0 1 2 3 4 5 6 7 8 9
Recv: 0 +7.491 +7.464 +7.424 +7.437 +7.461 +7.429 +7.409 +7.378 +7.359 +7.350
Recv: 1 +7.488 +7.480 +7.462 +7.490 +7.488 +7.472 +7.474 +7.446 +7.421 +7.359
Recv: 2 +7.386 +7.411 +7.419 +7.424 +7.434 +7.427 +7.404 +7.414 +7.394 +7.330
Recv: 3 +7.253 +7.286 +7.295 +7.305 +7.326 +7.319 +7.302 +7.320 +7.315 +7.275
Recv: 4 +7.191 +7.231 +7.249 +7.253 +7.270 +7.264 +7.256 +7.259 +7.275 +7.230
Recv: 5 +7.151 +7.199 +7.224 +7.222 +7.222 +7.220 +7.215 +7.229 +7.235 +7.179
Recv: 6 +7.094 +7.139 +7.146 +7.146 +7.146 +7.130 +7.106 +7.118 +7.137 +7.089
Recv: 7 +7.054 +7.110 +7.134 +7.119 +7.115 +7.089 +7.058 +7.074 +7.084 +6.994
Recv: 8 +7.044 +7.064 +7.052 +7.089 +7.044 +7.005 +6.991 +6.959 +6.986 +6.939
Recv: 9 +7.031 +7.016 +7.020 +7.028 +7.007 +6.955 +6.916 +6.891 +6.882 +6.884
was working fine.
any suggestions
thanks
Caleb
Sounds like you need to start your own thread because that doesn’t seem related to this topic of a specific firmware error.
There’s lots of bed levelling advice that can be found in the search tool.
ok thanks I thought it was due to the incorrect mesh points.
have a good night.
Looking at your numbers you bed is reasonably flat but it’s up at the front and down at the back. I wonder if some shims between the rail supports and the bed might work wonders. You would just need 4.
You can change M206 but it means the area you level will be shifted left and forward looking at the front of the machine. You also need to make sure you change it back before you do any printing. In addition the leveling is carried beyond the area measured and this can cause problems. As an example, if the measured points mean the nozzle has to go down towards the end of the measured area it will keep going down at the same rate so if your bed then goes up, it may hit the bed.
You also can’t use touch screen leveling as that puts M206 back to it’s current settings and you must make sure M206 is correct before printing as it’s not put back on power on.
I think @Brent113 is right and this is not your issue but if you want to try, this is my current levelling macro. Be very careful though, small steps and make sure you know what you are doing.
;bed level script bed heated to 65c
;bed heat is left on as usually doing a print after this.
G21 ;set units to millimetre
G90 ;set absolute positioning
M140 S65 ; set bed temp for bed level, heat while homing
G28 ;do this now, done in G1029 but takes ages
M190 S65 ; wait for bed temp
M206 x0 y0 ;remove workspace offset prior to levelling
M500 ;save change
;Auto Level
G1029 A ;start levelling
M114
G91; relative positioning for Z offset move
;*****************
G0 Z-xx.xx ;Device specific Z offset, reduce to bring print closer to the bed (bigger minus number). (equivalent to M851)
;*****************
M114
G1029 S ;save data
G1029 D0 ;end levelling
G90 ;restore absolute positioning
M206 x-19 y-10 ;Put workspace offset back on
M500 ;Make change permanent
G28; home all for safety
You need to put your own minus value in G0 Z-xx.xx. Do a touch screen levelling but take note of the distance you move the nozzle down and put the number here. Do small square test print to check the level and adjust with G1029 D-x.xx where minus -x.xx will bring the head down nearer the bed and positive x.xx will take it up. I move in 0.05mm steps.
I have also changed the firmware so it doesn’t switch off the heaters when doing a G1029 level but thats not crucial.
More detail of the idea behind this here but I now use this in a macro rather than have it in start GCODE.
Thanks, so much and sorry to post in wrong thread. Even though I have be printing for years, still struggle with bed leveling. I came from a cheap prusa clone, that had broken mounts and components which I have been fixing for years, so most of what I thought I knew was wrong. Then enter SM A350, and they do things differently like you mentioned with the z prob. I will try putting some shins between the bed frame and the y carriage mounts just the back 4 screws, 2 on each rail, and see if that helps.
I don’t quite understand how the bed could end up needing shim, I did have a nozzle hit the bed a few times in the back. In the begining. Maybe that was it.
Thanks again and good job on finding the mesh bug with the raw and non raw offset dimensions.
I will also try your script carefully 
and I like the idea of the macro to test the bed height, that is what I do with my old printer.
a small .5mm shim has made the world of difference, I also included M420 S1 in my start gcode as the prints were acting like bed leveling was not turned on…
| 7.175 | 7.184 | 7.169 | 7.249 | 7.267 | 7.274 | 7.325 | 7.234 | 7.226 | 7.184 |
|---|---|---|---|---|---|---|---|---|---|
| 7.429 | 7.415 | 7.387 | 7.456 | 7.389 | 7.4 | 7.456 | 7.37 | 7.349 | 7.182 |
| 7.361 | 7.43 | 7.414 | 7.436 | 7.412 | 7.382 | 7.415 | 7.327 | 7.26 | 7.095 |
| 7.316 | 7.364 | 7.34 | 7.356 | 7.302 | 7.287 | 7.31 | 7.217 | 7.15 | 7.02 |
| 7.3 | 7.356 | 7.294 | 7.327 | 7.241 | 7.207 | 7.23 | 7.131 | 7.1 | 6.967 |
| 7.315 | 7.342 | 7.31 | 7.322 | 7.202 | 7.167 | 7.186 | 7.115 | 7.081 | 6.926 |
| 7.295 | 7.332 | 7.274 | 7.287 | 7.204 | 7.135 | 7.147 | 7.052 | 7.017 | 6.895 |
| 7.286 | 7.361 | 7.319 | 7.309 | 7.229 | 7.161 | 7.167 | 7.095 | 7.021 | 6.887 |
| 7.31 | 7.34 | 7.264 | 7.287 | 7.206 | 7.106 | 7.139 | 7.047 | 7.026 | 6.891 |
| 7.341 | 7.3 | 7.239 | 7.226 | 7.166 | 7.089 | 7.076 | 6.997 | 6.925 | 6.875 |
is my mesh after the shim
woops just noticed that i shimmed the wrong corner lol
Thanks for your help.
Caleb