Klicky Probe bed_mesh_calibrate in Start cgode

[hopeinformer]

I want my prints to start with "home all" "QGL" and "bed mesh calibrate" before each print. I don't know how to set that up to do it. I have to manually home all and QGL, then also manually run the command "bed_mesh_calibrate" before I start a print. Then the printer will home all, QGL while heating up. Then it will home all and QGL again before it starts printing. I don't know why it does that so many times but it does. I tried setting up a conditional, CG32, but that does change it from doing it at least twice before each print. My guess is I have it set to home all and QGL in the start gcode macro and in the slicer's gcode. If I remove it from the slicer's gcode start it won't print but says there was an error loading the file. 

Edited July 9, 2022 by hopeinformer

[smirk]

I think you're probably onto something with the slicers startup gcode and any macros set up in the klipper config (printer.cfg). My V0 homes twice (it's a quirk I've just come to accept), but that is simply because I have a G28 in both the slicer's GCode start routine and the print_start macro I have defined in klipper. Naturally I call print_start as the first entry of my slicer's gcode startup. Clearly I'm just too lazy to fix it

If you want to do all those calibration activities (QGL, Bed mesh, homing) that you just call them in your slicer's start up or put in them in klipper macro (e.g. print_start). There's not really a right or wrong way, especially as you  need to call any Klipper macro as part of your slicer's startup gcode.

The "error loading file" when you modify the slicer's startup gocde is rather interesting. Which slicer are you using and how is it connected to the printer (is it using the octoprint "emulation" or is it a direct moonraker connection)? I've seen the "error loading file" type of error in the past but for me it's occurred when there's been a connectivity issue (e.g. the mDNS resolver on my laptop has decided to fail to properly resolve the name of my printer) rather than anything to do with the file being uploaded. At this moment, I can't think of a reason why a (potentially) mangled gcode startup section would cause the file to fail to load. Absolutely it might stop it printing as klipper cannot interpret it but not to stop it uploading.

[smirk]

That is a bit interesting. When you say it starts to print 3mm above the bed I take it you mean the entire first layer (well the entire model) is deposited into thin air 3mm above the bed? When you say you use the z-offset to reduce the gap, I take it you mean the z-offset buttons in the Mainsail/Fluid interface, rather than stopping and doing a Z_ENDSTOP_CALIBRATE? I might have been tempted to say it wasn't saving the new z-offset that you had set, or something in your pre-print startup was wiping it out, but then that would not account for the printer smashing the klicky probe into the surface.

Just checking the two events are connected - if you didn't manually adjust/correct the z-offset would the second print still smash the klicky probe into the bed or not?

[hopeinformer]

Thank you smirk for for your reply. I'm using SuperSlicer and the emulated octopi connection. I updated to the newest version of SS and haven't had an error. So that could've been the issue.

Now I'm having another issue which I don't understand. When I start to run a print the nozzle is about 3 mm off the bed. So I use the printer's z offset to bring it back to the bed. But then my next print during the bed mesh calibrate sequence it drags the Klicky probe across the bed and then gives the error " probe triggered prior to movement." Which would be expected since it's dragging the probe across the bed. But even if I move it to the first probe position and raise z by 10 when I start the calibrate it's still says the same error as it comes down to probe the first point. QGL works fine, calibrate_z works fine and I run those command before I do the bed_mesh_calibrate. Any idea why it's doing this and how to fix it?

[hopeinformer]

That's correct on all. It starts the print in mid air and I use the printer's "tune/z-offset" to bring it down to the bed during the print. I can use Mainsail to adjust the offset as well I just find the print's knob to be faster when the print is that high off the bed. 

It saved the new offset from before and now it's doing the same thing when trying to bed mesh calibrate. I haven't started any new prints yet, just trying to figure out why the probe is dragging on the bed. I'm messing with the printer now. (I shouldn't be since I have to get ready for work but I couldn't sleep and it's driving me crazy haha)

Edited July 9, 2022 by hopeinformer

[smirk]

2 hours ago, hopeinformer said:

I couldn't sleep and it's driving me crazy

I know that feeling!

[smirk]

I've yet to fit a klicky probe it's part of my new voron 0 build.I was trying to figure out the differences in the probe arms (or rather their lengths and how much distance between the bed and nozzle and klicky's switch).

Could it be something to do with the horizontal_move_z in the [bed_mesh] section, I think that governs the distance from the bed (z height) during travel moves between probe points. I just checked the documentation and it defaults to 5mm but I'm presuming with klicky you need to set that much higher because you've got  the probe dangling there. Would you need to increase your horizontal_move_z setting (possibly by more than 3mm) to compensate for your manual readjustment of the z-offset ?! Unless there's some other minimum z-height setting within the actual klicky settings - that's pure speculation as I've still to battle with it myself.

 

 

 

 

[hopeinformer]

I don't think it's the horizontal_move_z I have it set to 15

[smirk]

That strikes me as plenty, so I'd agree it's not that . The [probe] z_offset out of whack?  I'm trying to think how the general z-axis z_offset would interact/play with the z_offset for the probe (I think I'm overthinking that and confusing myself).

[smirk]

Thinking about this when I was walking the dog. This is a daft question, but it's not just a case of the probe incorrectly reporting? If you manually mount the klicky probe and then query the status (M114?) I would expect it to be "open", I'm also guessing that it would report "closed" if you hadn't mounted/attached the probe as that would be a safety feature to prevent the head smashing into the bed?!

[hopeinformer]

Haha I was overthinking it and confusing myself as well.

I don't think it's the price incorrectly reporting, but when I get home I'll check that out.

[hopeinformer]

Unfortunately it's not not the incorrect reporting from the probe. If I run the command "QUERY_PROBE" with it attached I get "Open" and if I dock the probe I get "Triggered."

[smirk]

Well I guess that's good news, we've eliminated the probe being faulty. Must be some weird probe off-set thing. I did see one thread somewhere but can't remember where and they were talking about having issues with probe positioning when the default printer acceleration was very high (the answer was some relatively undocumented klicky setting to limit acceleration for probe movements). That doesn't strike me as the issue here as surely it would be more variable rather than smashing the probe into the bed every time?! Although, having said that I wonder if there's some other not well-documented clicky setting at play here?

[claudermilk]

I would start with going back and double checking the slicer start gcode and your print_start macro. I use SuperSlicer and I've cut the start gcode down to a M104 & M140 per the Ellis tuning suggestion and calling my print_start macro. That macro handles everything else. In a nutshell, it conditional homes, sets to absolute, heatsoaks the printer, levels the bed, does a mesh, sets Z offset (Klicky calibrate_z), then prints.

[hopeinformer]

@smirkI going to check every .cfg file line by line. I'm hoping something pops out at me but honestly I probably wouldn't notice it haha. 

@claudermilkThe only thing in my start_print gcode is: CG32, G1 Z10 F3000 and calibrate_z (which doesn't do anything, I have to manually run the calibrate_z before each print). My SuperSlicer start print looks like this:

M140 S[first_layer_bed_temperature] ; set bed temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
M104 S[first_layer_temperature] ; set extruder temp
M109 S[first_layer_temperature] ; wait for extruder temp
G1 X0.0 Y0.0 Z0.3 F5000.0
G92 E0.0
G1 Z2.0 F5000
G1 X60.0 E9.0 F1000.0 ; intro prime nozzle line
G1 X120.0 E12.5 F1000.0 ; intro prime nozzle line

I'd love to see your print_start macro. I'm also using SuperSlicer. 
   

[smirk]

8 minutes ago, hopeinformer said:

I have to manually run the calibrate_z before each print

I might be being daft, but I don't see a call to print_start in the SS startup code. If your startup code doesn't explicitly call it then it won't happen (which might be why the calibrate_z is not automagically happening).

I also note there's no G90 (absolute co-ordinates) in the startup, personally I think there should always be a G90 otherwise the co-ordinate space can go a bit wonky as the printer things it's in incremental/relative space.

I don't use super slicer (but I have it) and my startup code is:

; M190 S0
; M109 S0 ; uncomment to remove set&wait temp gcode added automatically after this start gcode
print_start EXTRUDER={first_layer_temperature[initial_extruder] + extruder_temperature_offset[initial_extruder]} BED=[first_layer_bed_temperature] CHAMBER=[chamber_temperature]

 

[hopeinformer]

@smirkOMG. You're right about the not including "print_start" in my slicer start gcode. Thank you Smirk for all your help. I didn't know about the G90. I wonder if that's what's  causing my probe to crash into the bed during bed_mesh_calibrate.

Edited July 11, 2022 by hopeinformer

[hopeinformer]

So I just noticed under the "Bed Mesh" section of my config file the horizantal_move_z: 2 is commented out. I removed the # and saved/restart firmware. Then I get this error horizantal_move_z' is not valid in section 'bed_mesh' which is strange because this is where I'm having the issue with bed mesh calibrate. I'll keep looking, I know Klicky instructions said to comment this out. So maybe this is noted in another config file specifically for Klicky Probe.

[smirk]

I would've expected horizontal_move_z in the probe section rather than the bed mesh, thought it was just definitions for probe points, speed and "interpolation" in [bed mesh]. Could be wrong there. Suppose, the "trouble" with this FLOSS stuff is it keeps changing unexpectedly. So it's perfectly possible that combo was valid last week/month but not today  

Clearly I should just be grateful and just shut up 

[smirk]

The G90 could be a factor if the klicky probe is moving relatively rather than to an absolute position (e.g difference between lowering by another 6mm, or just moving to z=6mm)

[hopeinformer]

Oh... I'm going to give that a shot. Do you recommend Putting everything in the macro print_start in the printer.cfg and only "print_start" in the slicer, or should I add the G90 to the slicer? When a print starts which gets loaded first, the "print_start" from Klipper's config file or the slicer's start gcode?

Edited July 11, 2022 by hopeinformer

[hopeinformer]

Unfortunately the G90 didn't make any difference for the "bed_mesh_calibrate" part. Everything else still works fine. I can run a start gcode to home all, calibrate_z, QGL but still nothing changes the probe dragging across the bed to the first bed_mesh_calibrate point.

Maybe I need to run the BMC before I run calibrate_z

[smirk]

3 hours ago, hopeinformer said:

When a print starts which gets loaded first, the "print_start" from Klipper's config file or the slicer's start gcode?

It's the slicers gcode that gets "called" first as that is at the start of the file being printed. Best way to think of the klipper macros is custom GCODE commands that you've defined. There's nothing magic about them in the sense that klipper is doing something behind your back, they only get called if you explicitly reference them either in the console or from the GCODE you're sending to the printer (from a slicer). Personally, there's not really a right or wrong place to put the various commands (whether that's in a macro like print_start or the slicers startup code). I guess the advantage comes when those nice folks at VoronDesign (& friends) have already built a bunch of useful stuff and stuck it in a klipper macro.

Just because the macro is called print_start that's just happenstance they could've called it "make_it_so" or "twiddly_bop".

1 hour ago, hopeinformer said:

Maybe I need to run the BMC before I run calibrate_z

It's worth trying as an experiment just in case some action is leaving the printer in an "odd-state" that is then causing the issue with the klicky.

[smirk]

1 minute ago, smirk said:

I guess the advantage

I suppose one advantage of putting your configuration into a macro is that it stays "attached" to the printer so if you're using multiple slicers then you don't need to replicate a bunch of config.....however, you'd still need to remember to customise those slicers to simply call "print_start" or "twiddly_bop" or whatever. For me that's not much of an advantage,I don't swap slicers that often.

[hopeinformer]

@smirkHahaha twiddly_bop. I'm going to change it to that now.

Thank you for all your help. I'm going to put the bed mesh on hold for a bit. I can still print. I switched out my build plate for the authentic Mandala Roseworks and switched my PEI spring steel sheet for a descent powder coated one so the build surface is relatively smooth and level... for now. This Voron 2.4 is a work in progress. Eventually I'll figure out the bed mesh issue and then while I'm at it I'll figure out my filament sensor as well. Maybe when they release the official next version of the V2 series. Long term goal, I want this to be at least as suffocated as my MK3 so I can retire it and start building my Trident. 

[claudermilk]

OK, you asked for it...  Be warned, my print_start has gotten somewhat complex. Here's my printer config backup to peruse: https://github.com/claudermilk/TridentBackup A lot of what I have there was inspired by zellneralex's and Anrew Ellis' configs saved in GitHub.

My SuperSlicer start gcode is just this:

M104 S0 ; Stops PS/SS from sending temp waits separately
M140 S0
PRINT_START BED=[first_layer_bed_temperature] HOTEND={first_layer_temperature[initial_extruder]+extruder_temperature_offset[initial_extruder]} CHAMBER=[chamber_temperature] SIZE={first_layer_print_min[0]}_{first_layer_print_min[1]}_{first_layer_print_max[0]}_{first_layer_print_max[1]} FILAMENT={filament_type[0]}