[BUG]: wont load new mesh on ender 3

[519soldier]

Describe the bug when i click on the update mesh now button it will probe the mesh completely but when it is finished it just stays on the loading mesh screen and never loads it to view

Expected behavior i would expect it to show me the graph of the mesh

Debug Log plugin_bedlevelvisualizer_debug.log

Screenshots OctoPrint.pdf screenshot.pdf

Firmware and Version Bed Visualizer: 0.1.15

[jneilliii]

turn off center origin, restart octoprint, and try again and report back.

[widewing]

Same here, it breaks after update to latest version (0.1.15). Klipper on Ender 3. center origin is off

[jneilliii]

Try this release candidate by copying/pasting the url below into plugin manager > get more > ...from URL and clicking install.

https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/archive/1.0.0rc1.zip

[widewing]

Try this release candidate by copying/pasting the url below into plugin manager > get more > ...from URL and clicking install.

https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/archive/1.0.0rc1.zip

No this still not work unfortunately. I downgraded to 0.1.14 and that works.

[jneilliii]

Could I get you to enable the debug logging in the plugin's settings, restart octoprint and try the update mesh process again? Then grab the plugin_bedlevelvisualizer_debug.log file and drag it into a comment here so I can analyze the results being returned from your klipper setup?

[Thegs68]

Hi I have the same problem when using the BedLevelVisualizer with the latest release of Octoprint. But when I use the previous version of Octoprint and the latest bed leveler there is no crashing after the mesh has been generated. Hope this will help.

Greg Stay Safe, Stay Healthy

On Oct 11, 2020, at 9:30 PM, jneilliii notifications@github.com wrote:

 Could I get you to enable the debug logging in the plugin's settings, restart octoprint and try the update mesh process again? Then grab the plugin_bedlevelvisualizer_debug.log file and drag it into a comment here so I can analyze the results being returned from your klipper setup?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[jneilliii]

Same thing @Thegs68 kind of need to see the logs to understand what is being seen differently. I'm running the latest OctoPrint with the latest stable BLV version without issue running Marlin 2.0.7.1 UBL. I notice you replied via email, so you'll need to use the web page to upload the log file by dragging it into your comment.

[jneilliii]

also, double-check your octoprint.log for any errors related to numpy or the plugin.

[Thegs68]

Sorry for the delay. I upgraded to Marlin 2.0.7.1. Already running BedLevelVisualizer, Bed Visualizer (1.0.0rc1) from the link posted and BLTouch Plugin (0.3.4) along with OctoPrint 1.4.2 Python 3.7.3 OctoPi 0.17.0. But unfortunately it still crashes after the Bed Mesh sequence and disconnects from the printer. I unfortunately cannot find where the logs are, I'm new to this and don't know my way around yet. Can you tell me where they are so I can upload them? This happens for both Mac and Windows 10 and doesn't matter which browser used ie: Chrome, Safari, Firefox.....

[jneilliii]

Ok, Python 3... did you install libatlas3-base as documented in known issues?

[widewing]

I'm running OctoPrint 1.4.2 on python 2. Turned on debug logging. Not much information in it

octoprint.log plugin_bedlevelvisualizer_debug (1).log

[Thegs68]

OK found the files. Here you go. octoprint.log plugin_bedlevelvisualizer_debug.log

Greg

[jneilliii]

@widewing do you have auto leveling firmware and a probe for measuring your bed? The debug log indicates it never received data. You can verify by typing M115 in the terminal tab of OctoPrint and seeing if AUTOLEVEL setting equals 1 or 0. If it's 0 you don't have auto bed leveling.

[jneilliii]

@Thegs68 I'm not sure why the graph isn't working for you as it is collecting the mesh data. I think I'll need a little more info. Can you open your browser and press the F12 key on your keyboard to open the developer console and then open up your octoprint page and try to run the mesh and let me know if there are any errors reported during the process of loading the page or while the mesh is being collected?

[Thegs68]

I pressed F12 and opened the Console tab and watched for any errors before the crash/disconnect, but no errors showed up. The process came back saying nothing had changed and it was not saving the new mesh reading. That's all I got.

[widewing]

@widewing do you have auto leveling firmware and a probe for measuring your bed? The debug log indicates it never received data. You can verify by typing M115 in the terminal tab of OctoPrint and seeing if AUTOLEVEL setting equals 1 or 0. If it's 0 you don't have auto bed leveling.

I do have the auto leveling by bltouch. Actually when I click update, the console shows leveling data, but that's it, no further progress. As I said the behavior goes to normal when I switching back to older version, and all the debug messages just show up in the log

[jneilliii]

Ok, that's very strange. The only thing I can think of is to get a full serial.log from you guys then to try and debug the communication directly. If either or both of you could follow these steps it would be a great help in finding out what's going on. This serial logging should only be enabled just before you want to test the process and disabled right after because it can get quite big.

In OctoPrint settings enable log communication on the serial connection section and restart OctoPrint.

Run the update mesh process until it times out or says it's done and then disable the setting back and restart again. Once restarted share your serial.log file from OctoPrint's logging section.

[Thegs68]

Ok, I think I did correctly. Here is the log. serial.log

[Thegs68]

Never mind I'll try again.

[Thegs68]

OK, this time it has data. serial.log

Greg

[Thegs68]

Hi I tried to reinstall 1.1.5 and when I went to start the pluggin I had this message: "In order for this plugin to work properly, you must configure the GCODE commands necessary to send back a Bed Topography Report in Settings." Nothing works to get the Bed Visualizer back. all data and setup have gone. Can you please tell me what the GCODE for this to work properly are?

[jneilliii]

Thanks @Thegs68 for the serial log. I'll use that to work to reproduce the issue if I can. The error you mention relative to reinstall almost sounds like an old bug with OctoPrint. where if you use the option to uninstall and clean up data that the settings get corrupted in config.yaml and it's completely uneditable. In order to verify if this is the issue or not can you please check your config.yaml file in the bedlevelvisualizer section to see if it's set to null? If it is, then deleting the entire bedlevelvisualizer section should fix the issue.

[Thegs68]

Hi Where do I find the config.yaml file to check and uninstall? I look on both the OctoPi card and Marlin card and found nothing like this.

[jneilliii]

With the pi booted up you have to SSH to the pi and run the following command to edit config.yaml.

nano ~/.octoprint/config.yaml

This will open the file in a test editor and you can use the arrow keys to move down in the file. If you need to save the file just press ctrl and x at the same time and answer yes when prompted to save and then keep the same file name by just pressing enter when prompted for the filename. After that use the restart octoprint menu from the system menu to reload everything while not printing.

[widewing]

I just reviewed the code by comparing v0.1.14 and v0.1.15. I noticed one of the change is the using of threading in flag_mesh_collection(...). Is it possible that the self.processing flag is set after all of the mesh data returned, and then waiting infinitely?

[jneilliii]

I guess that could be possible, but I would think unlikely unless you're pulling the mesh data from EEPROM using M420 V and a stored mesh because the probing process alone takes time before it starts reporting the mesh offset values at the end of the process.

[widewing]

Actually for Klipper the mesh is stored in the host instead of in the board, it should be faster than eeprom

[jneilliii]

That's a good point, but are all of the people in this thread using Klipper?

[widewing]

No.. actually I believe there're two bugs. I updated the threading logic by set processing flag prior to thread starts, still not work, but the debug logging shows up (like other guys). In the log it read the data correctly, but after that a second mesh collection started is shown, and never ends.

EDIT: there's no "second mesh collection started", it just proves the threading is started after everything finished.

[2020-10-15 18:12:01,859] DEBUG: [u'-0.143750', u'-0.167130', u'-0.183287', u'-0.193750', u'-0.200046', u'-0.203704', u'-0.206250', u'-0.209213', u'-0.214120', u'-0.222500']
[2020-10-15 18:12:01,859] DEBUG: [u'-0.057299', u'-0.094665', u'-0.119879', u'-0.135448', u'-0.143876', u'-0.147671', u'-0.149336', u'-0.151380', u'-0.156306', u'-0.166620']
[2020-10-15 18:12:01,860] DEBUG: [u'0.002716', u'-0.042465', u'-0.072420', u'-0.090386', u'-0.099596', u'-0.103286', u'-0.104691', u'-0.107046', u'-0.113586', u'-0.127546']
[2020-10-15 18:12:01,860] DEBUG: [u'0.041250', u'-0.006728', u'-0.037994', u'-0.056250', u'-0.065201', u'-0.068549', u'-0.070000', u'-0.073256', u'-0.082022', u'-0.100000']
[2020-10-15 18:12:01,861] DEBUG: [u'0.063256', u'0.016345', u'-0.013682', u'-0.030725', u'-0.038684', u'-0.041458', u'-0.042948', u'-0.047052', u'-0.057671', u'-0.078704']
[2020-10-15 18:12:01,861] DEBUG: [u'0.073688', u'0.030557', u'0.003432', u'-0.011497', u'-0.018041', u'-0.020011', u'-0.021219', u'-0.025476', u'-0.036592', u'-0.058380']
[2020-10-15 18:12:01,862] DEBUG: [u'0.077500', u'0.039707', u'0.016265', u'0.003750', u'-0.001265', u'-0.002207', u'-0.002500', u'-0.005571', u'-0.014846', u'-0.033750']
[2020-10-15 18:12:01,862] DEBUG: [u'0.079645', u'0.047597', u'0.027736', u'0.017330', u'0.013648', u'0.013957', u'0.015525', u'0.015620', u'0.011510', u'0.000463']
[2020-10-15 18:12:01,863] DEBUG: [u'0.085077', u'0.058027', u'0.040760', u'0.031559', u'0.028705', u'0.030481', u'0.035170', u'0.041054', u'0.046415', u'0.049537']
[2020-10-15 18:12:01,863] DEBUG: [u'0.098750', u'0.074799', u'0.058256', u'0.048750', u'0.045910', u'0.049367', u'0.058750', u'0.073688', u'0.093812', u'0.118750']
[2020-10-15 18:12:01,864] DEBUG: {'z_min': 0, 'y_min': 0, 'x_max': 200.0, 'x_min': 0, 'type': 'rectangular', 'y_max': 200.0, 'z_max': 200.0}
[2020-10-15 18:12:01,864] DEBUG: stopping mesh collection
[2020-10-15 18:12:01,865] DEBUG: [[u'-0.143750', u'-0.167130', u'-0.183287', u'-0.193750', u'-0.200046', u'-0.203704', u'-0.206250', u'-0.209213', u'-0.214120', u'-0.222500'], [u'-0.057299', u'-0.094665', u'-0.119879', u'-0.135448', u'-0.143876', u'-0.147671', u'-0.149336', u'-0.151380', u'-0.156306', u'-0.166620'], [u'0.002716', u'-0.042465', u'-0.072420', u'-0.090386', u'-0.099596', u'-0.103286', u'-0.104691', u'-0.107046', u'-0.113586', u'-0.127546'], [u'0.041250', u'-0.006728', u'-0.037994', u'-0.056250', u'-0.065201', u'-0.068549', u'-0.070000', u'-0.073256', u'-0.082022', u'-0.100000'], [u'0.063256', u'0.016345', u'-0.013682', u'-0.030725', u'-0.038684', u'-0.041458', u'-0.042948', u'-0.047052', u'-0.057671', u'-0.078704'], [u'0.073688', u'0.030557', u'0.003432', u'-0.011497', u'-0.018041', u'-0.020011', u'-0.021219', u'-0.025476', u'-0.036592', u'-0.058380'], [u'0.077500', u'0.039707', u'0.016265', u'0.003750', u'-0.001265', u'-0.002207', u'-0.002500', u'-0.005571', u'-0.014846', u'-0.033750'], [u'0.079645', u'0.047597', u'0.027736', u'0.017330', u'0.013648', u'0.013957', u'0.015525', u'0.015620', u'0.011510', u'0.000463'], [u'0.085077', u'0.058027', u'0.040760', u'0.031559', u'0.028705', u'0.030481', u'0.035170', u'0.041054', u'0.046415', u'0.049537'], [u'0.098750', u'0.074799', u'0.058256', u'0.048750', u'0.045910', u'0.049367', u'0.058750', u'0.073688', u'0.093812', u'0.118750']]
[2020-10-15 18:12:01,866] DEBUG: mesh collection started
[2020-10-15 18:12:05,570] DEBUG: Canceling mesh collection per user request
[2020-10-15 18:12:05,570] DEBUG: Mesh data collected prior to cancel:
[2020-10-15 18:12:05,570] DEBUG: []
[2020-10-15 18:12:05,570] DEBUG: Mesh data after clearing:
[2020-10-15 18:12:05,571] DEBUG: []

[widewing]

FYI after reverting the threading completely, everything works as expect. Why the threading is added here? I see no blocking logic in the thread

[Thegs68]

OK I did a rollback to 0.1.14. But now I still get: "In order for this plugin to work properly, you must configure the GCODE commands necessary to send back a Bed Topography Report in Settings." So what are these gcode commands that I am missing? If I put in: G28 M155 S30 @BEDLEVELVISUALIZER G29 T M155 S3 I seems to be ok. Another note I before this happened I did do an uninstall with clear data. This is still happening with a fresh install of OctoPriint/OctoPi, blank gcode.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in 14 days. It will be closed if no further activity occurs in 7 days.

[jneilliii]

Does the same thing happen with the latest rc1? Copy/pate the URL below in plugin manager > get more > ...fromURL and click install.

https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/archive/1.0.0rc1.zip

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in 14 days. It will be closed if no further activity occurs in 7 days.

[slant]

For what it's worth, I am also experiencing this same issue.

Ender 3 Pro OctoPrint 1.5.3 Python 2.7.16 OctoPi 0.17.0 Bed Level Visualizer 1.0.0rc1

When I click "Update Mesh Now," I am greeted with "Please wait, retrieving current mesh" which never goes away.

[jneilliii]

Open a separate ticket with all the requested information to further assist you.