Zet, I would say the first one has a minimal correction to the bed so it shows green.
The second picture shows the left side had to have a correction of around 1mm to level the bed.
In my experience, the left side low can be adjusted by manually pulling it up or pulling the right side down with the power off, it depends on what type of printer you use, the vertical lead screws or stepper motors may need to be checked. I don't use visualiser to level the bed, I use the printers bed leveling function and then use the visualizer to check and record what the settings are.
Hi, thanks for your comment. I think you misunderstood what I was trying to say.
What visualiser showed to be a flat bed was not.
The second picture IS a flat bed. But visualizer shows it being left side up
The plugin only graphs what it is given from the firmware during the probe process, or via a mesh report query command. The whole point of ABL is to compensate for these inconsistencies/warping of the bed, and it's best to start by squaring your z axis to the frame (both sides left and right are equidistant from the frame base to the bottom of the gantry). Depending on your printer, some people have designed leveling blocks to aid in this process. One the x-axis gantry is square/"level" to the frame then manually level the bed to the nozzle with the old paper trick and then probe the bed. This way you are minimizing the amount of z axis compensation during the print.
Thank you, I will check Z axis position and report.
I've re-checked the geometry and everything seems to be pretty square.
Still, if I enable UBL it tries to compensate for the slant that isn't there and ruins the print.
I understand this is not caused by the plugin, it only reports what firmware G29 has measured.
But then what is going on?
Could you explain some details about your printer and probing setup? Is it BL Touch or some other probe?
Hi, Charlie.
It is a custom built CoreXY machine. A heavily modified Hypercube with servo controlled dual hotend and a 3dTouch (BLtouch clone) probe.
M48 shows probe is fairly consistent.
And it consistently measures left side of the bed to be higher than it actually is. As per pictures I initially posted.
The only way this could happen would be if the distance between the probe and nozzle would change as the head moves towards the left.
But his is impossible since both are rigidly attached to each other.
Finally found what the problem was: geometry.
Skewed X gantry bars.
Apologies.
Alright Everyone...
Having a problem tonight with this plugin. Everytime I start octoprint the plugin works as intended. The problem comes in after I adjust the bed according to the visual display. After I make my adjustments and hit the update mesh button the plugin freezes at "Please Wait, Retrieving Current Mesh."
Heres a copy of my GCODE Commands...
M140 S60 ; starting by heating the bed for nominal mesh accuracy
M117 Homing all axes ; send message to printer display
G28 ; home all axes
M420 S0 ; Turning off bed leveling while probing, if firmware is set
; to restore after G28
M117 Heating the bed ; send message to printer display
M190 S60 ; waiting until the bed is fully warmed up
M300 S1000 P500 ; chirp to indicate bed mesh levels is initializing
M117 Creating the bed mesh levels ; send message to printer display
M155 S30 ; reduce temperature reporting rate to reduce output pollution
@BEDLEVELVISUALIZER ; tell the plugin to watch for reported mesh
G29 T ; run bilinear probing
M155 S3 ; reset temperature reporting
M140 S0 ; cooling down the bed
M500 ; store mesh in EEPROM
M300 S440 P200 ; make calibration completed tones
M117 Bed mesh levels completed ; send message to printer display
G28
In order to get the plugin working I need to restart Octoprint.
Any help will be appreciated.
it should also eventually time out. typically it's because the plugin isn't getting the expected response from the printer. enable debug logging for the plugin, restart OctoPrint, and try the update mesh process. see if it timeouts and is back after the timeout configured in settings. afterwards grab the file plugin_bedlevelvisualizer_debug.log from OctoPrint's logging section and share it here. Also check the terminal tab in OctoPrint to see what's being sent/received to/from the printer and OctoPrint during the process. It might shed some light into what's happening as well.
Here is the debug log
plugin_bedlevelvisualizer_debug.log (11.6 KB)
I have run the plugin again and it seems that when it sends the M500 ; store mesh in EEPROM the printer stops and no more of the remaining commands are sent.
Any help would be appreciated.
Here is a copy of the latest terminal session...
Send: G28
[...]
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
[...]
Recv: X:147.00 Y:110.00 Z:12.30 E:0.00 Count X:11804 Y:8888 Z:4920
Recv: ok
Send: M420 S0
Recv: echo:Bed Leveling Off
Recv: echo:Fade Height Off
Recv: ok
Send: M117 Heating the bed
Recv: ok
Send: M190 S60
[...]
Recv: ok
Send: M300 S1000 P500
Recv: ok
Send: M117 Creating the bed mesh levels
Recv: ok
Send: M155 S30
Recv: ok
Send: G29 T
[...]
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 +0.023 +0.033 +0.057
Recv: 1 -0.051 -0.005 +0.052
Recv: 2 -0.038 -0.046 -0.010
Recv:
Recv: X:216.00 Y:214.00 Z:12.31 E:0.00 Count X:17345 Y:17291 Z:4920
Recv: ok
Send: M155 S3
Recv: ok
Send: M140 S0
Recv: ok
Send: M500
Recv: echo:Settings Stored (614 bytes; crc 21972)
Recv: echo:Poweroff Stored (56 bytes; crc 29205)
Recv: Write file name: ok
I honestly can't say. There's nothing that looks out of the ordinary in the log or terminal output and the plugin is seeing data. I wonder if it's an issue with the SD card in the printer somehow causing it to lock up. There are some firmware versions from creality that use SD card to store eeprom data.
Running Marlin 1.1.8
And there is no SD card present connecting to printer through USB from Raspberry PI 4B
I got it almost perfect but it just gets annoying having to restart octoprint after every run of the plugin.
If you take the M500 and following commands out from the plugins settings does it still lock up?
Ok I took out..
M500 ; store mesh in EEPROM
and it will now let me run the plugin again...
1 Like