Print sometimes not using mesh bed leveling - startup gcode
-
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" -
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 P0So just tpost0 is doing something
-
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?
-
Do you have any
M376taper 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?
-
@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.
-
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.csvIt 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?
-
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.
-
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 modeWith 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!
-
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?
-
@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
-
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.
-
@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
-
@comediantf2 use drop box or some sort of cloud storage
-
