Print sometimes not using mesh bed leveling - startup gcode

[ComedianTF2]

Hey ya'll, I have a weird issue that I can't seem to figure out. At my work there is a printer with a duet 2 and automatic bed leveling, but it seems as if it doesn't always use that automatic bed leveling. The employee that left that was in charge of this printer used to be able to get it to run, and when I use his printer profile it works, but after I made changes to the gcode it doesn't work anymore.

Now I know that the simple solution would be to reuse his startup code, but I'd like to also learn what I did wrong!

Working startup code:

;FLAVOR:RepRap
;TIME:16112
;Filament used: 13.6238m
;Layer height: 0.3
;Generated with Cura_SteamEngine 3.4.1
T0
M190 S45
M104 S190
M109 S190
M82 ;absolute extrusion mode
G90
M82
G29 S1
T1 ; solve firmware bug < I haven't been able to find anything on this
G1 E20 F3000 ; Extrude 100mm material before printing to clean up nozzle
G92 E0 ; solve firmware bug extruder position 0
T0 ;solve firmware bug < or this
G1 E-2.0000 F3000
G1 Z2.050 F1200
M83 ;relative extrusion mode

Not working
;FLAVOR:RepRap
;TIME:18039
;Filament used: 10.8348m
;Layer height: 0.4
;Generated with Cura_SteamEngine 3.6.0
T0
M190 S45
M104 S190
M109 S190
M82 ;absolute extrusion mode
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to relative mode
G28 ; home all axes
G29 S1 ; use mesh level
G1 Z20 F9000 ;move the head 20mm up for CYA clearance
G92 E0 ; zero the extruded length
G1 E25 F500 ; Extrude 25mm of filament
G1 Z0.5 ; move nozzle close to bed
G92 E0 ; zero the extruder length
G1 E-2.0000 F3000
M83 ;relative extrusion mode

[Cecil]

Isn't mesh bed leveling in tool change g-code? That's run during T0 / T1 commands.
Check macros "tfree0.g" "tpre0.g" "tpost0.g"

[ComedianTF2]

Just checked those commands, and they seem to contain nothing of interest:

; tfree0.g
; called when tool 0 is freed
;
; generated by RepRapFirmware Configuration Tool v2 on Thu Feb 07 2019 14:48:49 GMT+0100 (Midden-Europese standaardtijd)

; tpre0.g
; called before tool 0 is selected
;
; generated by RepRapFirmware Configuration Tool v2 on Thu Feb 07 2019 14:48:49 GMT+0100 (Midden-Europese standaardtijd)

; tpost0.g
; called after tool 0 has been selected
;
; generated by RepRapFirmware Configuration Tool v2 on Thu Feb 07 2019 14:48:49 GMT+0100 (Midden-Europese standaardtijd)
; Wait for set temperatures to be reached
M116 P0

So just tpost0 is doing something

[Phaedrux]

Can you post your config.g and the homing files as well? Is there a bed.g present?

What firmware version? What style of printer?

Do you mean auto bed leveling where it adjusts lead screws to level the bed, or do you mean mesh bed compensation where it actively adjusts the z height based on X Y position?

[nhof]

Do you have any M376 taper height for bed level applied? Could be that the Z20 move in your non-working script is high enough to disable the bed compensation.

Not sure it works that way but the old script has no similar Z move.

What type of machine is it?

[Phaedrux]

@nhof that's plausible. The firmware looks for the first z move in the gcode file to determine first layer hight. And if that height is beyond the taper height it may cancel it? But the firmware would also be aware of the actual z height and once the print gcode starts the z height will return to actual first layer height.

If that does end up being the cause you can work around it be moving the start code into start.g which won't get parsed as part of the print gcode file and the proper first layer height will get picked up.

[ComedianTF2]

Sure, here are the the files:

5_1550218730449_homez.g
4_1550218730449_homey.g
3_1550218730449_homex.g
2_1550218730449_homeall.g
1_1550218730449_config.g
0_1550218730449_bed.g
I also uploaded the hightmap: 0_1550218850813_heightmap.csv

It is a huge bed that isn't fully meshed (it's a 1000x1000x1000mm printer, and the bed leveling does X150 to X850 and Y100 to Y800 (700x700) at 35mm spacing for probing, for 400 points total. Firmware maxes out at 441 points and that's the area i'm most confident in. Gonna expand it to 840x840 at 40mm, but leveling already takes 45 minutes so I wanna fix this bug first.

The prints were both placed within the meshed area (I just doublechecked to make sure, the functioning boat was at the corner where it barely stayed in, the non-functioning one was much closer to the middle)

it's firmware 2.02(RTOS) (2018-12-24b1), it's a cartesian printer.

I mean mesh bed compensation where it adjusts the Z-height.

@nhof I couldn't spot any M376 in the files linked above, where else might I need to spot that?

[dc42]

I don't see anything in your slicer start GCode that would account for that problem.

You can send M376 with no parameters to check whether taper is in use.

You can send M122 and look in the report for the "Bed compensation in use:" field to check whether mesh bed compensation is being applied.

[ComedianTF2]

Using M376 gives "Bed compensation is not tapered"
M122 gives "Bed compensation in use: mesh"

I took another look at the startup gcode, and noticed it had M82 in it twice, as well as G28 to home all axes, whereas the working one doesn't.

I figured to try to see if the code would work with those two changes. I also added the T1 and T0 commands for the heck of it.

M82 ;absolute extrusion mode
G90 ;absolute positioning
G29 S1 ; use mesh level
T1 ; solve firmware bug
G0 Z5 F9000 ;move the head 5mm up for clearance
G0 X170 Y120 ;move to 170x120
G92 E0 ;Zzero the extruded length
T0 ;solve firmware bug
G0 Z0.2
G1 X300 E50 F300 ; Extrude 50mm of filament
G92 E0 ;Zero the extruded length
G1 E-1 F500 ; slight retract
G1 X400 F4000 ;Move away a bit, quickly
G1 Z1 ; Move up a bit
M83 ;relative extrusion mode

With this startup gcode, it works again!

I took this gcode, and added the G28 command again between G90 and G29 S1, to see if that might have caused it, but that worked fine. I tried the same with the T1/T0 removed, and adding a second M82 command, but nothing.

I have no clue why it's suddenly working again, but when I run that original file with that original gcode, it doesn't work at all, and now any file I try it does work. I am glad it works now, but I can't tell you why it does!

[Phaedrux]

Your config.g is set to use M83 for relative extruder moves. What is your slicer set to use? It doesn't really matter which you use, as long as it's consistent. Relative is generally prefered. The firmware will use relative moves internally anyway.

I seem to recall that Cura will insert it's own M82 commands regardless of what you have in the startup code and what it's set to use. It doesn't matter since it inserts them before the start gcode. I'd probably remove them.

Is Cura configured with multiple extruders? Just trying to understand the possible reasons for the T0/T1 commands.

I can't see anything else off in your config files.

Do you have a start.g macro in the sys folder?

What does your current working start code look like?

[ComedianTF2]

@phaedrux The slicer is set to relative extruder mode. Only set to a single extruder at the moment, but there is a second extruder that will be used later on. It's currently not wired up so haven't enabled it in the firmware. Nobody seems to know why that original startup gcode had the T1/T0 commands in it, and what bugs they were ment to fix. The working gcode is the one linked in the previous comment i made

[dc42]

If you can give me two GCode files with the same GCode except for the startup code, which do and don't work, then I'll try to reproduce this.

[ComedianTF2]

@dc42 I can't upload the files here, they're over the size limit (5,5mb/15mb), what would be the best way of send it to you? sorry for being a bit slow, was sick for a few days

[Phaedrux]

@comediantf2 use drop box or some sort of cloud storage

[ComedianTF2]

https://www.dropbox.com/s/xlzhcwm6c8qfyar/benchy_not working.gcode?dl=0
https://www.dropbox.com/s/2kg1cpzdxq78m8h/benchy_working.gcode?dl=0