Closed mike00107 closed 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?
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?
/\ 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….
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?
/\ 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
So it works for like 3 times and after that it stops..
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.
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 ;)
Hmm, unfortunately I have no way personally to debug iOS/Apple devices. Does chrome do the same?
Chrome for IOS acts the same sadly.. thank you for the help!
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?
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.
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?
Right now I am running iOS 16.0 but there is an update for 16.1 so might try that tomorrow.
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
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.
Ahh yeah that is a better explanation of the issue ;) i hope jneiliii looks at it again
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).
Hmm yes insuspect is an iOS issue, sadly refreshing does not update it for me.
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
Initial Baseline Mesh Debug Log
Second mesh after killing browser (note: it hasn't been updated)
Second debug log (note: a new mesh was collected, but visualization failed to update)
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.
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???
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.
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).
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.
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 ;-)
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