Bed level values are not updated after mesh bed levelling

[tpellegrini]

This is a repeat of issue #45. My observations are similar.

The behavior occurs regardless of whether it is a new session or the continuation of an existing session.

In the first case of a new session (i.e. starting a new mesh level): Click Begin Adjusting The screen displays the status "Idle" The extruder starts moving and the display immediately changes to "Results received; make adjustments now. When ready, click continue below."

When continuing to adjust in the same session (Case 2): Click the ">> Continue" button: The screen shows "Waiting for mesh level to complete." The extruder starts moving and the display immediately changes to "Results received; make adjustments now. When ready, click continue below."

I have noticed that the issue does not occur using Chrome 99.0.4844.74 but was observed running Chromium-based Microsoft Edge 99.0.1150.36.

I have attached videos showing the behaviors for both cases. Note that the length of the video is directly related to the extruder movement. That is, when the video ends, the extruder has finished moving.

https://user-images.githubusercontent.com/26607300/158713023-61265735-18e9-47cc-878a-bbbb0ec9ee59.mp4 https://user-images.githubusercontent.com/26607300/158713024-a45e7a81-8f5c-4600-98b9-3209c3087cff.mp4

Let me know what else I might do to assist you with troubleshooting.

OctoPi 0.18/OctoPrint 1.7.3 Prusa Mk3s 3.10.1, MMU2s 1.0.6 plugin 1.0.17

[tpellegrini]

Sorry, I just realized my video was using preheating. In this case clicking the "Begin Adjusting" first goes to temp stabilization, and then the process begins. No real difference as you can see, the heading changes far too quickly for the polling to have occurred.

Also, I neglected to mention I am using 7x7 points.

Thanks!

[scottrini]

Hey there,

So first, this isn't related to issue #45 at all, that was very different. I understand the similarities between the overall title, though.

My first instinct was that I don't really care about Edge support, it's a pretty small share of a pretty small share of users. But I went ahead and tested it locally, but I only have Edge 99.0.1150.39 and I can't reproduce the issue in this version.

Seeing your video, I know exactly what line is failing for you: https://github.com/scottrini/OctoPrint-PrusaLevelingGuide/blob/master/octoprint_PrusaLevelingGuide/static/js/PrusaLevelingGuide.js#L420

In Edge, it's either receiving the data from the REST call differently or it's not tracking the local variable the same. But every time it runs that test to see if they differ, it's testing true and moving forward (even though it shouldn't).

I'm sure if I could reproduce it or even if I was on a screen share and saw devtools while this was occurring, I could say exactly what's going on.

[tpellegrini]

Thanks for your response. First off, I apologize for making a false assumption. I should simply have stated my observation was very similar to that other issue.

More importantly, my Edge browser has also updated—to 99.0.1150.46—and I am no longer seeing this issue.

Thanks for taking the time to address my concern, and thanks for the great tool!

[scottrini]

That's awesome, glad to hear it was resolved!