Please wait, retrieving current mesh.

[pjotter1986]

Hello please i need some help your plugin keeps tellling please wait, leaving current mesh. How to fix this problem? I am on flsun cube printer.

[pjotter1986]

Leaving = retrieving

[jneilliii]

You probably just need to set the correct data collector flag and gcode settings for your firmware.

[satiromarra]

I have the same problem. When i click on button "Update" show the message "Please wait, retrieving current mesh." the printer start calculating the positions and on after stop calculating, the message not dissappear. My data collector is "Bed Topography Report:" My GCODE commands "M155 S30 G28 G29 T M155 S3" I tried with GCODE commands "G28 G29 T"

[AcHub]

I have the same issue. I use Bilinear Leveling Grid and the Gcodes "G28" followed by "G29 T" which does work in general.

However every first time I try to get the bed mesh after I start the printer, I get the Error "Please wait, retrieving current mesh.". This seems to be repeatable. It seems to be an issue with G29 T, because G28 is executed fine, but then it stopps and waits forever.

In Terminal view I see: Send: G29 T Recv: echo:Unknown command: "" Recv: ok

If I send "G29 T" a second time manually in terminal, the printer starts to measure the bed level and finishes successfully, showing the current graph.

[satiromarra]

My error is a invalid option " Data Collector Flag" value. G29 T returns me: Send: G29 T [...] Recv: Bed Height Topography: [...]

Now the mesh has data.

[jneilliii]

@satiromarra, set your data collector flag to Bed Height Topography:

@AcHub: can you please post a screeshot of your plugin settings? I think your GCODE command script may be incorrect. Are the two commands on separate lines and there aren't any extra lines in there are there?

[AcHub]

Two separate lines of Gcode, no extra lines etc.

Also, if I trigger an extra G29 T manually via terminal once, the next time I update the bed leveling in the plugin, it works perfectly and as it should.

[jneilliii]

@AcHub: To confirm, these are the steps to reproduce...

1. Restart printer physically as if it was just powered on.
2. Switch to Bed Visualizer tab. At this point stuck on "please wait".
3. Terminal tab reads Unknown command "", etc.
4. Manually run G29 T
5. Mesh is valid and displays on tab.

Can you upload the bedlevelvisualizer section of your config.yaml please?

[AcHub]

Exactly: 1) Turn on Printer. Connect Octoprint 1.3.8 on Octopi 0.13.0 to the printer (Wanhao D6 with inductive Probe connected to z stop switch pin). Printer is running on Marlin 1.1.7 based Firmware from https://github.com/dot-bob/Marlin-Duplicator-6 2) Go to Bed Visualizer tab. Tab shows a graph of the bed based on stored values. Click on "Update". Plot disapears and it says "Please wait, retrieving current mesh". Printer is Homing X/Y and rising printbed for homing Z. Z Homing is successful after a few seconds (My bed is typically lowered all the way away from the nozzle, so it takes a while).

3) Terminal shows: Send: G28 Recv: T:24.30 /0.00 B:22.70 /0.00 @:0 B@:0 Recv: echo:busy: processingPrinter seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly Recv: T:24.37 /0.00 B:23.12 /0.00 @:0 B@:0 Recv: echo:busy: processing Recv: T:24.22 /0.00 B:22.77 /0.00 @:0 B@:0 Recv: echo:busy: processing Recv: T:24.37 /0.00 B:22.97 /0.00 @:0 B@:0

(.......These two lines of "busy" and temp-reads repeat for another approx. 20 times......)

Recv: echo:busy: processing Recv: T:24.53 /0.00 B:22.89 /0.00 @:0 B@:0 Recv: X:65.00 Y:115.00 Z:5.00 E:0.00 Count X:5203 Y:9205 Z:2002 Recv: ok Send: G29 T Recv: echo:Unknown command: "" Recv: ok Send: M113 S2 Recv: ok Recv: T:24.45 /0.00 B:23.05 /0.00 @:0 B@:0 Recv: T:24.53 /0.00 B:22.81 /0.00 @:0 B@:0 (.....and so on....)

4) If I run G29 T manually immediately after the "Unnown command", the bed leveling is measured as expected and the plot is shown. However if I wait too long with entering G29 T, it says: "Send: G29 T Recv: echo:Vorher XYZ homen Recv: ok" and I will have to run G28 manually before G29 T (which then works fine).

I first thought that it may be some sort of timeout because my z homing takes so long, but when I tried to reproduce this by lowering my printbed again all the way and then run a second "Update" in Bed Visualizer, it works just fine. Also I did the opposite and raised the bed 10mm below the nozzle, restarted the printer and then updated in Bed Visualizer, which then fails the first time.

The bedlevelvisualizer section of config.yaml: bedlevelvisualizer: mesh_timestamp: 25.4.2018, 14:47:10 report_flag: 'Bilinear Leveling Grid:' stored_mesh:

• • '-0.050'
    • '+0.074'
    • '+0.049'
    • '-0.058'
• • '-0.133'
    • '+0.005'
    • '+0.025'
    • '-0.065'
• • '-0.113'
    • '+0.015'
    • '+0.015'
    • '-0.025'
• • '+0.059'
    • '+0.114'
    • '+0.147'
    • '+0.089'

[satiromarra]

@jneilliii This is my configuration:

[jneilliii]

@satiromarra, I think I just figured out the false error message, uploading now.

[jneilliii]

I've pushed an 0.1.0 branch that simplifies the data collection process drastically. Can you please try this one by installing the plugin from the URL below and let me know if it helps with your errors?

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

[AcHub]

Well... it depends.... In terms of the "Please wait, retrieving current mesh"-Message which would not go away if the update fails - that went away as soon as the "command unknown"-Error showed in Terminal. But then it still shows the old plot based on old stored values.

In terms of the Gcode errors I can report as follows. At first it failed again as before when I used the Gcodes: M155 S30 G28 G29 T M155 S3

With the same error in Terminal as before: Send: M155 S30 Recv: ok Send: G28 Recv: echo:busy: processingPrinter seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly Recv: echo:busy: processing Recv: echo:busy: processing .... Recv: echo:busy: processing Recv: echo:busy: processing Recv: T:25.08 /0.00 B:23.40 /0.00 @:0 B@:0 Recv: echo:busy: processing Recv: echo:busy: processing .... Recv: echo:busy: processing Recv: X:65.00 Y:115.00 Z:5.00 E:0.00 Count X:5203 Y:9205 Z:2002 Recv: ok Send: G29 T Recv: echo:Unknown command: "" Recv: ok Send: M155 S3 Recv: ok

But then I thought that I misplaced the M155 S30 in the GCode (before G28 instead of after G28) because temperature was continuously reported in terminal before Z finished homing and G29T was sent. So I restarted the printer and changed the GCode to: G28 M155 S30 G29 T M155 S3

Which, according to the Terminal view, also did not work (in terms of that all gcodes were properly executed), but gave me an odd response (highlighted in bold). It seems that the next Gcode sent by the plugin after G28 is never recognized correctly:

Send: G28 Recv: T:25.31 /0.00 B:23.52 /0.00 @:0 B@:0 Recv: echo:busy: processingPrinter seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly Recv: T:25.23 /0.00 B:23.75 /0.00 @:0 B@:0 Recv: echo:busy: processing ..... Recv: T:25.39 /0.00 B:23.71 /0.00 @:0 B@:0 Recv: echo:busy: processing Recv: X:65.00 Y:115.00 Z:5.00 E:0.00 Count X:5203 Y:9205 Z:2002 Recv: ok Send: M155 S30 Recv: echo:Unknown command: "" Recv: ok Send: G29 T Recv: T:25.23 /0.00 B:23.67 /0.00 @:0 B@:0 Recv: echo:busy: processing .... Recv: T:25.23 /0.00 B:23.67 /0.00 @:0 B@:0 Recv: echo:busy: processing Recv: Bilinear Leveling Grid: Recv: 0 1 2 3 Recv: 0 -0.045 +0.092 +0.054 -0.048 Recv: 1 -0.153 +0.007 +0.025 -0.148 Recv: 2 -0.193 -0.003 -0.003 -0.535 Recv: 3 +0.035 +0.099 +0.114 -0.083 Recv: Recv: T:25.31 /0.00 B:23.63 /0.00 @:0 B@:0 Recv: X:154.00 Y:190.00 Z:5.00 E:0.00 Count X:12326 Y:15208 Z:2027 Recv: ok Send: M155 S3 Recv: ok

So now G28 worked, G155 did not, but G29 T worked. I could confirm this by adding any GCode right after G28 in the plugin settings, in my example I added M31 (report printing time) to the gcodes, which then gave me: Send: M31 Recv: echo:Unknown command: "" Recv: ok Send: M155 S30 Recv: ok Send: G29 T Recv: echo:busy: processing

So If use M31 as a "non-functional" Gcode right after G28, then the plugin works fine and updates the plot with new and reported values.

As before with Version 0.0.8, all of this only happens the first time I use the Plugin after I start the printer. If I update the mesh plot a second time, all Gcodes are executed correctly and with no error message sent. So maybe there is an issue in the way the gcodes are recognised from the settings and then sent to terminal?

[satiromarra]

@jneilliii Using version 0.1.0 The graphic is better.

Send: M155 S30
Recv: ok
Send: G28
Recv: X:136.00 Y:150.00 Z:10.90 E:0.00 Count X:13600 Y:15000 Z:4360
Recv: ok
Send: G29 T[...]
Recv: 
Recv: Bed Height Topography:
Recv:    +--- BACK --+
Recv:    |           |
Recv:  L |    (+)    | R
Recv:  E |           | I
Recv:  F | (-) N (+) | G
Recv:  T |           | H
Recv:    |    (-)    | T
Recv:    |           |
Recv:    O-- FRONT --+
Recv:  (0,0)
Recv:  +0.14944 -0.09056 +0.00694
Recv:  +0.07944 -0.16306 -0.02306
Recv:  +0.11194 -0.10056 +0.02944
Recv: 
Recv: X:218.99 Y:210.00 Z:10.80 E:0.00 Count X:21900 Y:21000 Z:4360
Recv: ok
Send: M155 S3
Recv: ok

[jneilliii]

Thanks for ther detailed report @AcHub, quick question on the unknown command part. If you put @BEDLEVELVISUALIZER just above the G29 T command does it make any difference?

[AcHub]

@BEDLEVELVISUALIZER doesn't work. it's also not visible in terminal view. There is only G28 (success) and then G29 T, which fails.

[jneilliii]

Yeah, it never reports back, it's just an instruction to the plugin to start collecting. Make sure it's all caps...

What is happening is the collector stops when it receives an ok command, and if that flag isn't in the gcode you enter the ok is coming earlier than expected.

[AcHub]

It was all caps. The collection works fine for me IF an other non-disturbing gcode is sent before G29 T. So I will currently stick to my M31-solution as a workaround

[jneilliii]

Yeah, that makes me think there is some odd character in the GCODE setting that when I split it on a return it is coming in as a blank command, therefore triggering the OK. I'll look into either changing the split logic, or running the split object through a cleaner to remove the blanks. I think you're not the only one effected by this, and is a better long term solution.

[jneilliii]

Just pushed new code to 0.1.0 branch that should help with extraneous blank commands being sent. May help in your situation.

[ItsVince1234]

I have te same issue, what fixed it? It says Send: G29 T Recv: Mesh bed leveling has no data.

[AcHub]

Just tested with your 0.1.0 branch but still getting blank commands sent. (Is it on purpose that your master branch is pointing to V0.0.8?)

I am pretty sure now that the Gcode commands in the settings are beeing messed up while saving them, leading to an extra line in the settings and therefore an extra "gcode" fragment with no content. I just had a look at my config.yaml again and while the last time (6 days ago) the gcodes were not part of the file, they now are and clearly the Gcodes are saved with extra line breaks that weren't there in the User input field in the plugin settings:

bedlevelvisualizer: command: 'G28

  M31

  G29 T'
mesh_timestamp: 1.5.2018, 12:39:43
report_flag: 'Bilinear Leveling Grid:'
stored_mesh:
- - '-0.073'
  - '+0.017'
  - '+0.079'
  - '+0.010'
- - '-0.170'
  - '-0.063'
  - '+0.030'
  - '-0.040'
- - '-0.110'
  - '+0.002'
  - '+0.052'
  - '+0.015'
- - '+0.054'
  - '+0.102'
  - '+0.144'
  - '+0.079'
stored_mesh_x:
- 0
- 67
- 133
- 200
stored_mesh_y:
- 0
- 67
- 133
- 200
stored_mesh_z_height: 180

So something adds extra line breaks. To find out if that is something browser related I updated my config via the normal plugin settings tab using two other browsers (internet explorer and Edge, I'm usually working with firefox), but both didn't solve the issue and IE even gave me new issues (i'll open another ticket for that).

Also I tried to find out what is transfered from the browser to the server when saving the settings. I'm not sure if I got the right info but maybe it helps anyway. The JSON response of the settings POST is the following (bedlevelvisualizer only):

So tl;dr: line break identification and transfer from and/or to the config.yaml are not working.

[jneilliii]

The extra line breaks are somewhat normal when dealing with yaml I think. Mine looks similar.

[jneilliii]

I could try converting the commands to an array and storing them the same as the stored_mesh, but I don't think that is going to make a difference in your situation.

[jneilliii]

I just went back to look and it appears that the version number should be showing as 0.1.0, that's how it is configured in the setup.py. If you are seeing anything other than that, the version you installed is not the 0.1.0 one. Please verify you are installing using this url in plugin manager.

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

[AcHub]

I did use this URL and 0.1.0 was installed. Did a reinstall just now to make sure but the issue is still unchanged

[jneilliii]

@ItsVince1234, sorry I missed your post. The message that you received makes me believe that you haven't ran an auto bed leveling routine, so there is no data to report. Check you firmware documentation on how to do that.

@AcHub, I think your workaround is good for now, but I'd be curious if you copied the gcode below into a text document, save it as a gcode file and send it to the printer as a print if it performed the same way or not.

G28
M155 S30
@BEDLEVELVISUALIZER
G29 T
M155 S3

[jneilliii]

@AcHub, one more thing to check. When you run the process without the workaround implemented and look in the browser's console log, there will be an array returned of the commands that get sent to OctoPrint. Can you verify what that is coming back as for me please?

[AcHub]

I did run it as a gcode file and it now seems to me as if all of this is either a firmware or octoprint bug, and not caused by your plugin. In my start Gcode I also have G28 and G29, which - now that I payed close attention to it in Terminal - also seems to give the same error, but is then corrected automatically by resending the "lost" command. I will comment the Terminal protocol in italic-bold and highlight key findings in bold for better understanding:

Changing monitoring state from "Operational" to "Printing" (Begin of Start Gcode) Send: N0 M110 N0*125 Recv: ok Send: N1 M107*36 Recv: ok Send: N2 G28*17 Recv: T:24.30 /0.00 B:22.62 /0.00 @:0 B@:0 Recv: echo:busy: processing Printer seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly Recv: T:24.37 /0.00 B:22.38 /0.00 @:0 B@:0 (....) Recv: X:65.00 Y:115.00 Z:0.37 E:0.00 Count X:5203 Y:9205 Z:148 Recv: ok Send: N3 G29*17 Recv: echo:Unknown command: "" Recv: ok Send: N4 G1 Z2 F1000*3 Recv: Error:Line Number is not Last Line Number+1, Last Line: 2 Recv: Resend: 3 Recv: ok Send: N3 G29*17 Recv: T:24.69 /0.00 B:22.46 /0.00 @:0 B@:0 Recv: echo:busy: processing (...) Recv: T:24.53 /0.00 B:22.66 /0.00 @:0 B@:0 Recv: echo:busy: processing Recv: Bilinear Leveling Grid: Recv: 0 1 2 3 Recv: 0 -0.078 -0.000 +0.072 -0.048 Recv: 1 -0.220 -0.068 +0.015 -0.048 Recv: 2 -0.158 -0.003 +0.040 -0.153 Recv: 3 +0.045 +0.099 +0.134 +0.040 Recv: Recv: X:147.00 Y:195.00 Z:2.30 E:0.00 Count X:11766 Y:15608 Z:965 Recv: ok Send: N4 G1 Z2 F1000*3 Recv: ok Send: N5 G1 X100 Y100 F5000*79 Recv: ok Send: N6 G92 E0*65 Recv: T:24.53 /0.00 B:22.62 /0.00 @:0 B@:0 Recv: X:100.00 Y:100.00 Z:2.00 E:0.00 Count X:8004 Y:8004 Z:795 Recv: ok Send: N7 M900 K0.1*105 Recv: ok Send: N8 M117 Printing...*19 Recv: ok (End of Start Gcode, Begin of Test-Gcode File) Send: N9 G28*26 Recv: T:24.77 /0.00 B:22.54 /0.00 @:0 B@:0 Recv: echo:busy: processing (...) Recv: T:24.45 /0.00 B:22.73 /0.00 @:0 B@:0 Recv: echo:busy: processing Recv: X:65.00 Y:115.00 Z:0.37 E:0.00 Count X:5203 Y:9205 Z:148 Recv: ok Send: N10 M113 S2*80 Recv: ok Send: N11 M155 S30*98 Recv: ok Send: N12 G29 T*85 Recv: echo:busy: processing (...) Recv: echo:busy: processing Recv: Bilinear Leveling Grid: Recv: 0 1 2 3 Recv: 0 -0.068 +0.015 +0.077 -0.055 Recv: 1 -0.218 -0.055 +0.025 -0.055 Recv: 2 -0.158 +0.002 +0.042 -0.180 Recv: 3 +0.059 +0.112 +0.157 +0.049 Recv: Recv: X:147.00 Y:195.00 Z:2.29 E:0.00 Count X:11766 Y:15608 Z:969 Recv: ok Send: N13 M155 S3*80 Recv: ok Send: N14 G91*36 Recv: ok Send: N15 G1 Z3*85 Recv: ok Send: N16 G92 E0*112 Recv: X:147.00 Y:195.00 Z:5.29 E:0.00 Count X:11766 Y:15608 Z:2170 Recv: ok Send: N17 G1 E-1.5 F500*47 Recv: echo: cold extrusion prevented Recv: echo: cold extrusion prevented Recv: echo: cold extrusion prevented Recv: ok Send: N18 M104 S0*92 Recv: ok Send: N19 M140 S0*93 Recv: ok Send: N20 M106 S0*85 Recv: ok Send: N21 G90*35 Recv: ok Send: N22 G28 X0 Y0*34 Recv: T:24.53 /0.00 B:22.46 /0.00 @:0 B@:0 Recv: echo:busy: processing Recv: echo:busy: processing Recv: X:0.00 Y:0.00 Z:5.42 E:-1.50 Count X:0 Y:0 Z:2170 Recv: ok Send: N23 G1 Z150 F9000*56 Recv: ok Send: N24 M84*41 Recv: T:24.61 /0.00 B:22.73 /0.00 @:0 B@:0 Recv: echo:busy: processing (...) Recv: ok Changing monitoring state from "Printing" to "Operational"

So I guess we did a lot of troubleshooting in the wrong place, sorry for that. Do you want the browser console log anyways?

[jneilliii]

Thanks, no need for the browser logs. I did post on the OctoPrint Github on a post related to this error here, and @foosel thinks it's probably firmware related as well. You may want to see if there are any possible updates for your printer, or just keep on with the workaround for this plugin.

[OutsourcedGuru]

Just installed this.

I note that the Terminal tab indicates "Recv: echo:Home XYZ first" but of course I wouldn't necessarily know to visit that tab since I'm currently on the Bed Visualizer tab and it's grinding away, waiting for me to do something.

So I then go to the Control tab and dutifully do as suggested, homing X/Y and then Z. The Terminal indicates that things are now happening. I used G29 T, btw.

Send: G29 T
Recv: echo:Home XYZ first
Recv: ok
[...]
Send: G91
Recv: ok
Send: G28 X0 Y0
Recv: echo:busy: processing
Printer seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly
Recv: X:0.00 Y:127.00 Z:-11.80 E:0.00 Count X: 0 Y:10160 Z:-9440
Recv: ok
Send: G90
Recv: ok
Send: M113 S2
Recv: ok
[...]
Send: G91
Recv: ok
Send: G28 Z0
Recv: echo:busy: processing (x 12)
Recv: X:0.00 Y:127.00 Z:148.20 E:0.00 Count X: 0 Y:10160 Z:118560
Recv: ok
Send: G90
Recv: ok

After watching that continue to grind, I edited it to G29 T1 in the settings and restarted OctoPrint.

Send: G29 T1
Recv: G29 Auto Bed Leveling
Recv: echo:busy: processing
Printer seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly
Recv: echo:busy: processing (x 22)
Recv: Eqn coefficients: a: 0.00835692 b: -0.00406008 d: 4.86226034
Recv: 
Recv: Bed Height Topography:
Recv:    +--- BACK --+
Recv:    |           |
Recv:  L |    (+)    | R
Recv:  E |           | I
Recv:  F | (-) N (+) | G
Recv:  T |           | H
Recv:    |    (-)    | T
Recv:    |           |
Recv:    O-- FRONT --+
Recv:  (0,0)
Recv:  -0.47736 -0.36111 +0.29014
Recv:  -0.42611 +0.12264 +0.35264
Recv:  -0.29986 -0.01236 +0.81139
Recv: 
Recv: 
Recv: 
Recv: Bed Level Correction Matrix:
Recv: +0.999965 +0.000000 +0.008357
Recv: +0.000034 +0.999992 -0.004060
Recv: -0.008357 +0.004060 +0.999957
Recv: X:116.06 Y:85.97 Z:7.46 E:0.00 Count X: 9280 Y:6880 Z:6463
Recv: ok
Send: M113 S2
Recv: ok

It would be nice if that Recv: echo:Home XYZ first could appear in your tab during the update process, if seen.

M115: FIRMWARE_NAME:Marlin 1.1.7-C2 (Github) SOURCE_CODE_URL:https://github.com/Robo3D/Marlin-C2 PROTOCOL_VERSION:C2 MACHINE_TYPE:RoboC2 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff EMERGENCY_CODES:M108,M112,M410 Version: OctoPrint 1.3.8 running on OctoPi 0.15.0

[jneilliii]

@OutsourcedGuru, when you first installed the plugin did you get the wizard dialog to configure your GCODE script?

[OutsourcedGuru]

@jneilliii Yes. Per earlier threads I thought the expected setting was G29 T so I used that initially. I then changed this to G29 T1 per this thread and it then worked. I mostly note that the critical information seeking a home event is only seen on the Terminal tab.

[jneilliii]

Thanks. Either G29 T or G29 T1 should work, thanks for the feedback...pulled previous release and am implementing this change once I test.

[Steve2Q]

Hi..I have not been able to get a finished graph. I have an Ender 3 with a BLtouch running with Octoprint. It stops at "Please wait, retrieving current mesh". I am running the unified firmware from TH3d with their EXboard Lite. What information (log, etc.) would you need? Thank you.

[jneilliii]

Enable debug logging, restart octoprint, try the process. If it doesn't work, share screenshot of your settings and the plugin_bedlevelvisualizer_debug.log from the logging section of octoprint's settings.

[Steve2Q]

Thanks for the reply. I did a bit more reading, and found that I had forgotten a character in the Gcode! I works fine now. Thanks

On Thu, Jun 18, 2020 at 2:35 PM jneilliii notifications@github.com wrote:

Enable debug logging, restart octoprint, try the process. If it doesn't work, share screenshot of your settings and the plugin_bedlevelvisualizer_debug.log from the logging section of octoprint's settings.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/issues/37#issuecomment-646237004, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIHN2J7G5BNFEMR2YCRHMLLRXJM75ANCNFSM4E4G4O3Q .

[Spiderjerusalem1]

hi, I have the same problem with an Ender 3 V2. I read all articles regarding the problems and tried anything out but still getting no visualization. Does anone have other way to solve that problem?

Thank you in advance