Bed Level Visualizer

I just checked in PrusaSlicer, and you can import config from gcode (probably only if the gcode was generated by PrusaSlicer).

Try from the menu: File/Import/Import Config... and load one of your gcodes. I haven't tried this myself, but since you have a need why not give it a shot? Also, for future reference it might be advisable to save the project .3mf file once you've settled on the customized slicer settings for a print project. That way you can get back to the settings you used for more tuning.

Thanks again.

I’ll try and see what config details I can find

And you are correct about 3mf plan.

I shall add Dòing that to my workflow. Just laziness on my part

Andy

Hi everyone, i have an Anycubic i3 Mega with a X-Carriage MK3 and Piezo. I would like to install the plugin „bed level vizualizer“ but I‘m not shure how to setup it correctly. Could someone help me? Do I have to change someting in my start gcode in the slicer or just in octoprint? This is my start gcoden in the slicer

Thx a lot

Hello @Dare !

Keep the Start Gcode untouched.

You have to setup the BLV accordingly to your printer in the BLV settings: See the wiki

the BLV settings should look something like this. Screenshot 2021-03-01 082443

Which wil result in something like this:

Mind you, the 'm420 s1 z10' in my Octoprint startup GCODE is doing absolutely nothing for my first layer

The M420 S1 Z10 has another purpose:

[Z<linear>] 	Set Z fade height (Requires ENABLE_LEVELING_FADE_HEIGHT)

* With Fade enabled, bed leveling correction is gradually reduced as the nozzle gets closer to the Fade height. Above the Fade height no bed leveling compensation is applied at all, so movement is machine true.
* Set to 0 to disable fade, and leveling compensation will be fully applied to all layers of the print.

from:

So it should just be an 'M420 S1' in general?

Thanks a lot! So that means, if I put this gcode to the BLV this would not effect anything in my prints? This is just to see the visualization... because in the code i see the M500.. sorry for the noob questions...

It works, thanks a lot!

Better use the G29 command appropriate the levelling you use:

So i shoud us G29 instead of G29 T right?

No, please see the wiki.

G29 has a bunch of parameters.
When I mentioned the G29 command above as a better use than M420, it was meant as an abbreviation for all the features it has.

1 Like

Yeah, those parameters are all different as well based on the type of leveling that you enabled in firmware, so your specific gcode requirements may be different than what I've listed in the docs. But based on the fact that it worked already, those should be the right settings.

1 Like

Hi. So I just got a Geeetech A30T the other day and wanted to jump right into Octoprint stuff. I was messing with Bed Visualizer today and I just could not get it to work. Which is understandable, I am using stock firmware. But I shut off the Pi and printer for a while and came back to them, connected to Octoprint, clicked the Bed Visualizer tab and it started doing its thing without me pressing "update mesh now". But it worked that time. I changed nothing at all, I pressed "update mesh now" and it again gave me the error :

Error:

TypeError: Failed to execute 'uniformMatrix4fv' on 'WebGLRenderingContext': Overload resolution failed.

Received Data:

[object Object]

I am just curious, why would it work fine that one time and then 10 other times, it doesn't work? It def means mesh leveling is enabled in this stock Geeetech firmware. I put G28 and G29 in the GCODE cuz it is basically a creality clone, but it never worked, except that one time when I didn't even press the update button. Any thoughts?

The only time the plugin will probe without pressing the button is if you don't have the option Save Mesh enabled. In that case it will run whatever you have configured for the update mesh button. My best guess is that it worked that time because the plugin received a mesh it understood and subsequent times it did not. The best way to tell is to enable debug logging in the plugin's settings, restart octoprint and try a couple of times to get it to work, or fail, etc. the more data available the better. Make sure to watch what your printer does when pressing the button and check the terminal tab for what it's doing. Then if it's still broke share your plugin_bedlevelivisualizer_debug.log file on here by dragging it into your comment.

plugin_bedlevelvisualizer_debug.log (9.6 KB) I tried that 'Save Mesh' setting on and off so I don't remember if it was enabled or disabled at the time of it working that one time. I honestly can't think of what even made it work, because I tried for a hour or two, took a break for about 8 hours and then it magically worked, but then wouldn't work again. But I appreciate the help

Really high numbers in that log for probe points. The best suggestion I can think of is setting the option for relative z offset and the z limits to auto,auto.

I enabled the "Use Relative Z Offsets" which I think is what you said, though the setting is named differently and managed to do two successful back to back mesh updates. I Googled and found previous comments of yours helping others and def want to add that the Octoprint restart is important, which I wouldn't have known without your comments helping others. I am gonna shut this off for now and mess with it more later, but I am feeling pretty confident it should be fine. Thank you

Hello. I have encountered an issue. I have recently had a bltouch sensor die on me, so i made a servo probe for bed levelling. Everything works just fine, except one thing. For some reason when I add the "@BEDLEVELVISUALIZER" to the Gcode Commands for Mesh Update Process, my servo arm will deploy, then stow, and then execute G28 and G29. This is bad, as my head will crash. When i remove the command, the G28 and G29 execute properly. I cnan recreate these results through the terminal as well by executing "@BEDLEVELVISUALIZER" then G28. My arm will deploy then stow and try and auto home. Just wondering if anyone else has encountered this issue and has any advice on it. Thank you in advance.

Your firmware shouldn't react that way to the @ command. But that @ command should also not be before G28, it should be after G28 and before G29.