Bed Variance doesn't seem to update correctly after measurements (OctoPrint 1.5.2)

[spiff72]

Hello,

I just tried running this tool this morning, and I am finding that the behavior of the plugin may have changed after I upgraded to OctoPrint 1.5 (using 1.5.2 currently).

When the mesh leveling runs, and it provides the numbers to adjust the screws, I go ahead and make the adjustments, but after it rechecks the mesh levels, the bed variance value doesn't update after the mesh check completes. If I click continue again (without making any changes to the screws), the bed variance value updates (as well as the screw values) as the mesh check BEGINS (or is partially complete).

My recollection of how this used to work (it has been a few months since I checked it) is that the mesh runs, and after it completes the measurement, the values for the bed variance and the screw values update, showing the newly calculated variance and screw turns needed.

I don't know if it makes a difference, but here are my settings for the plugin:

G28 W ; home all without mesh bed level M400 G80 N3; mesh bed leveling G81 ; check mesh leveling results

and the "move" is: G1 Z60 Y210 F6000

[spiff72]

I recorded a video showing how this behaves for me: https://www.youtube.com/watch?v=FVkx5qM_Oeg

Video is still processing as I post this, but it should be available momentarily.

[spiff72]

I also noticed that when the value updates, the message switches back to "Waiting for Continue", well before the level measurement is completed.

[spiff72]

Another update on this issue:

I just ran this again to dial in the bed for a large flat part (filling up the bed), and when I ran it today, it seemed to work as expected. I didn't change anything, but I do think I rebooted my Octoprint server since I last ran this leveling guide plugin - so maybe it was just a temporary glitch?

I will leave this open for now and try again in a few days. If operation still seems normal I will close this issue out.

[scottrini]

Hey there - so I actually thought I responded yesterday, but obviously I spaced on that. It's strange because I know I had something typed out, so I'm glad you updated again so I can provide some feedback here.

First, that's awesome you got it working, but also very strange. Almost all the code is client-side (javascript), there's very little server side. So typically starting fresh is just reloading the browser, not the entire octoprint server. So that's really strange and it could only be a few things...

With that being said, the only times I've seen strange behavior like this is when other plugins were installed that manipulated gcode as it was received/sent. However, I don't necessarily think that's the case here, it's just the only time I've seen anything similar to this.

I appreciate you went out of your way to include a video, but unfortunately, to really debug, we'd need to see what's going on in the terminal tab. Obviously the plugin sends the configured mesh level gcode to initiate the mesh leveling, but then it sits in a holding pattern and waits for the results ("Waiting for mesh level to complete"). So we'd need to inspect whether or not those results are coming back and how the plugin reacts when it does. So if you do run into this again and want to capture a video, please try to capture the terminal tab so we can see more closely what's going on.

I do also assume you're using the latest version of the plugin. I only mention this because there was an update to the prusa fw (I think it was .9.1) that changed the output for the results and actually broke several plugins that counted on it being the same, so the latest was absolutely required just to get the plugin to work.

Anyway, again, glad to hear it's working, but that's really odd that restarting the server would fix it. The only theory I have is that one of the variables it uses to hold state on the server-side hadn't been properly re-initialized I could probably add a route and REST call to clear these values at the start of the process, but that's a bit of work to do without knowing for sure this is the issue, so I'll keep tabs on this.

[spiff72]

Thanks for the response - I will leave this open as I mentioned above and if it acts up i will look at the terminal next time. I am using 1.0.12 (which appears to be the latest version of your plugin).

[spiff72]

And my printer firmware is 3.9.1-3518

[ddpt83]

Hey, I have the same problem with the same versions of programs. 3.9.1 for the FW and 1.0.12 for the plugin. The data is refreshed at the start of the measurement. They are of course false. To get the right data, I have to click on "finished" after the measurement and refresh. Daniel

[ddpt83]

I have to continue the tests. When I use PrusaLevelingGuide after initialization, everything is fine. I can do several cycles of measurements. I also use the "Bed Visualizer" plugin to have the measurements by point. In this case, after launching this plugin at least once, the PrusaLevelingGuide measurements are refreshed before the measurement. To return to the normal procedure, all you have to do is finish the cycle by clicking on 'Finished'.

[scottrini]

So I haven't been able to reproduce anything like this, but I hadn't updated to OctoPrint 1.5.2 and I do not have the bed visualizer plugin installed. The one I used to use - PrusaMeshMap - uses the same kind of hook to capture the results and update the graph. So whenever either plugin would perform a mesh bed leveling and get results, they'd both update.

@ddpt83

I also use the "Bed Visualizer" plugin to have the measurements by point. In this case, after launching this plugin at least once, the PrusaLevelingGuide measurements are refreshed before the measurement.

By this, you mean if you launch bed visualizer at least once? or LevelingGuide? You mean if you use bed visualizer then go to Leveling Guide you see this behavior? Also, if you refresh the browser, does it start working? If that doesn't help, does it get fixed if you restart the octoprint server?

I just updated to OctoPrint 1.5.2. I'm going to see if I can reproduce with that alone. If not, I'll try installing bed visualizer and kick it around.

[scottrini]

Alright, so I was able to reproduce this, but not just with OctoPrint 1.5.2. I had to install the bed visualizer plugin and load that first like @ddpt83 mentioned. If I use that first, then go Leveling Guide, I see similar behavior - and the numbers seem to be vastly different. A refresh of the page fixes things, though. So I'll take a look and try to identify how this other plugin is interfering, but I'm not sure there's much I'd be able to do.

[ddpt83]

@scottrini Knowing the problem, I can normally use the Leveling guide plugin.

[spiff72]

Hmm - I have this PrusaMeshMap plugin as well (but it hasn't worked for me at all in quite some time). The image never updates for me, even though I have disabled my uBlock Origin for my octoprint web pages.

This is the one (just checking that this is the same one you were all referring to): https://github.com/PrusaOwners/OctoPrint-PrusaMeshMap

This doesn't look like it has been updated for at least 2 years.

Could removing this other plugin eliminate the problem? I can't do it now because I have another 20+ hour print running...

Thanks!

[scottrini]

PrusaMeshMap was broken with the fw update like mine was. That's what I was referring to previously. It needs an update in order to work with the latest prusa fw because of the change in the mesh values output.

That plugin won't cause any of the behavior we've been discussing here, though.

[scottrini]

Should be fixed in 1.0.13