jneilliii / OctoPrint-BedLevelVisualizer

MIT License
369 stars 82 forks source link

[BUG]: bed mesh does not update #566

Closed mike00107 closed 1 year ago

mike00107 commented 1 year ago

Describe the bug When I try to update my bed mesh it will start probing but when it’s finished it won’t update to octoprint. This problem started after updating octoprint to version 1.8.3.

Expected behavior It worked fine before the update.

Debug Log

[2022-09-21 18:28:32,555] DEBUG: mesh collection started

Screenshots

This is the code (I got it from github and modified it to not heat my bed)

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 probing 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 M500 ; store mesh in EEPROM M300 S440 P200 ; make calibration completed tones M300 S660 P250 M300 S880 P300 M117 Bed mesh levels completed ; send message to printer display

jneilliii commented 1 year ago

Thanks for your report, if you open your browser's developer tools (f12 on your keyboard typically) and check the console tab do you see errors listed during it at the end of the update mesh process?

mike00107 commented 1 year ago

Thanks for your report, if you open your browser's developer tools (f12 on your keyboard typically) and check the console tab do you see errors listed during it at the end of the update mesh process?

image

/\ these errors are from when i still had the issue /\

i just found out it only probed the middle of the bed a few items. that caused me to look at the gcode and replace it with a fresh copy of the github code.

by the looks of it i made a mistake in the plugin settings gcode and it worked fine

[edit 17:28] I just got home and tried it again, but it stopped working….

mike00107 commented 1 year ago

Thanks for your report, if you open your browser's developer tools (f12 on your keyboard typically) and check the console tab do you see errors listed during it at the end of the update mesh process?

image

/\ these errors are from when i still had the issue /\

i just found out it only probed the middle of the bed a few items. that caused me to look at the gcode and replace it with a fresh copy of the github code.

by the looks of it i made a mistake in the plugin settings gcode and it worked fine

[edit 17:28] I just got home and tried it again, but it stopped working….

So yeah it stopped working… here is the gcode that I am using now. It worked fine this morning.

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 probing M117 Creating the bed mesh levels ; send message to printer display @BEDLEVELVISUALIZER ; tell the plugin to watch for reported mesh G29 T ; run bilinear probing M500 ; store mesh in EEPROM M300 S440 P200 ; make calibration completed tones M300 S660 P250 M300 S880 P300 M117 Bed mesh levels completed ; send message to printer display

mike00107 commented 1 year ago

So it works for like 3 times and after that it stops..

jneilliii commented 1 year ago

There is no reason for the plugin to only work x amount of times. the logic is always the same, so it sounds like your printer might not be responding every time with the mesh data. For further debugging you'll need to enable debug logging in the plugin's settings, serial logging in OctoPrint's settings and restart OctoPrint. Once restarted try the process a couple of times until it fails and then once it has failed share octoprint.log, plugin_bedlevelvisualizer_debug.log and serial.log files from OctoPrint's logging section.

mike00107 commented 1 year ago

here are the logs you requested. i have noticed somethig strange tho. when i do bed probing via PC it keeps working but when i go mobile IOS safari it starts to bugg. it looks like i am going to be pc bound ;)

octoprint-logs.zip

jneilliii commented 1 year ago

Hmm, unfortunately I have no way personally to debug iOS/Apple devices. Does chrome do the same?

mike00107 commented 1 year ago

Chrome for IOS acts the same sadly.. thank you for the help!

jneilliii commented 1 year ago

Maybe it's a memory related issue or something or an unusual problem with plotly.js library. Do all the examples load when you go to this page?

https://plotly.com/javascript/3d-surface-plots/

mike00107 commented 1 year ago

when i load it on my ios device it works just fine.. and i dont think its the printer not reporting anything becouse everytime it will show a bed mesh in the logs.

jneilliii commented 1 year ago

very strange bug indeed. I'll see if I can find an iOS device laying around the office to test with. What iOS version are you running?

mike00107 commented 1 year ago

Right now I am running iOS 16.0 but there is an update for 16.1 so might try that tomorrow.

github-actions[bot] commented 1 year ago

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

jr-free commented 1 year ago

Howdy,

Doing some digging, found this thread and figured I'd bump it.

I've found that I've ran face first into this same issue: mesh update works fine on PC, but is no bueno on Safari on iOS.

I've additionally found that if you prevent the iOS browser/phone from idling during the mesh generation process, it will complete with no issues. Killing the browser, changing apps, etc. however will result in the mesh plot not updating.

Curiously, it seems like my debug logs all capture the updated meshes after probing completes, they are just never visualized or updated on the frontend. Need to verify before declaring this with certainty.

Anyway, just wanted to share.

mike00107 commented 1 year ago

Ahh yeah that is a better explanation of the issue ;) i hope jneiliii looks at it again

jneilliii commented 1 year ago

I've additionally found that if you prevent the iOS browser/phone from idling during the mesh generation process, it will complete with no issues. Killing the browser, changing apps, etc. however will result in the mesh plot not updating.

ok, so this seems like something relative to the communication between front-end and back-end being blocked while the app isn't active? not sure there's anything I can do about that, sounds like an iOS "safety/security" feature. If the mesh completes though, it should just be a matter of refreshing the page for it to visualize the stored mesh (assuming that option is enabled).

mike00107 commented 1 year ago

Hmm yes insuspect is an iOS issue, sadly refreshing does not update it for me.

jr-free commented 1 year ago

Hey all,

I had a potential 'a-ha' moment while noodling on this problem: I wanted to see if I could emulate this behavior on a PC browser. My logic here being that (maybe) when the iPhone idles or one switches changes apps, iOS under the hood effectively kills the browser. To this end, if the bed visualizer were able to obtain new meshes on a PC when the browser is killed mid-probe, then this would be an isolated iOS problem. Spoilers: seems it's a general problem related to the browser dying.

To test this issue I did the following: 1) Ran a complete initial baseline mesh / bed visualization and recorded the log output 2) Ran a second mesh update and killed the browser mid-data collection 3) Wait until the second measuring procedure completed 4) Reloaded the browser and examined the bed visualization and debug log.

See below for images.

Initial Baseline Mesh baseline browser

Initial Baseline Mesh Debug Log browser baseline debug log

Second mesh after killing browser (note: it hasn't been updated) after 2nd probe browser

Second debug log (note: a new mesh was collected, but visualization failed to update) after 2nd probe debug log

jneilliii commented 1 year ago

Thanks for the additional debugging. I'll have to see if I can re-create. One other thing to check is that config.yaml is getting updated or not with the new data when the browser is closed. That's where the "stored mesh" option loads it's data from to display on initial page load/tab activation.

bobrossfrobro commented 1 year ago

I too am now having similar issues where it appears my mesh may not be saving properly. I have no problems completing the probing process, but it's very clear when I print that it wasn't saved. Furthermore, when the probing completes, I keep getting repeating notifications on my printer's display of "M220" and "M221," as if it still hasn't completed the whole process. The beeping just goes on and on...

Any advice???

plugin_bedlevelvisualizer_debug.log

jneilliii commented 1 year ago

Well, your log definitely indicates that it's collecting the data. Are you in the same situation where this is happening in the same browser (iOS Safari), I have no idea where you are getting the M220/M221 commands from, the plugin only sends what you tell it to in the plugin's settings.

bobrossfrobro commented 1 year ago

This is happening in multiple browsers on my Win10 machine (Chrome, Firefox, and Edge). As to the M-codes, I'm actually getting those on the printer display screen (see attached).Screenshot_20230124_194844_Gallery.jpg

jneilliii commented 1 year ago

Try adding M75 at the beginning of the gcode commands and M77 at the very end and try again. I'm not sure what that M221 is coming from.

bobrossfrobro commented 1 year ago

So, unfortunately, I had to concede this battle as none of the commands worked, and then on top of that my Octoprint started a sad downward spiral and I got so many errors coming back from Marlin that I just had to wipe both my Pi and redo the firmware on the Ender. I tried re-installing the visualizer with a clean, current Marlin config, but it just started causing tons of comms errors and crashes, I just had to resort back to doing leveling on the printer and leaving it at that.

Thanks for your assistance! I hope to reinstall this plug-in and try it again in the near future. On to my next problem ;-)