the BLV settings should look something like this. 
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...
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.
Yeah, I had an issue with the firmware, and stored eeprom settings on my sd card. The problem i was experiencing here is all fixed now. Now, there is something strange in the firmware itself. For some reason, M190 S60 command makes my printer want to change filament, but thats not because of this octoprint plugin, bed level visualizer. kinda weird, just use G4 to wait instead of M190.
you sure you didn't transpose those commands? M160 M600 is filament change I think.
No, i didn't transpose them i don't think. Manually entering the M190 or M600 command seems to initiate a filament change. It's weird.
I got it sorted. Silly me had Low instead of HIGH for my filament runout sensor. Typical of when your modifying firmware at 3am.
1 Like