I'm in the process of simplifying/improving the Bed Level Visualizer processing and need examples of what is returned by these firmwares when you run an autoleveling command, from start to finish, including temperature, wait, and busy notices. The easiest way to get this would probably be to enable serial.log in settings, run the command and then upload your serial log file here and then disable serial logging. Any help is greatly appreciated.
@foosel, relative to this question, is there an internal module/property that I can use to know what firmware is detected by OctoPrint?
What about Klipper users?
Oh yeah, forgot about you guys. Could use that one too.
Smoothieware - Rectangular Grid Compensation
NOTE:
M375.1 - display the current grid
I manually sent M375.1 to show the grid (and that is what BLV sends). I go against Smoothieware recommendation to only probe once and instead probe before every print so my routine may be different than others.
serial.log (5.7 KB)
Thanks @kantlivelong, since you're one of the few I know running Smoothieware, do they support some way to send something back to the host controller like M118 in Marlin and Repetier? I pose the question to you too @raymondh since I'm not familiar with Klipper's capabilities either.
I don't probe usually when I use the Bed Level Plugin. I just load a saved mesh (I keep a mesh for different bed temp) and output it. https://github.com/KevinOConnor/klipper/blob/1460e0d6f41753eb4d149819716125ae46af423b/docs/Bed_Mesh.md#output
So with the plugin you just use BED_MESH_OUTPUT and it graphs it? The reason that works is because the plugin receives the offset data and is able to collect it. What I'm trying to determine is if there is a better way to detect the start and end of that process.
Currently the plugin looks for the @BEDLEVELVISUALIZER flag on the communication layer to notify the plugin to start collecting data. The problem is that other data may be received between the time that collection starts and when the process is started on the printer and returns the mesh offsets. Couple of examples are temperature polling and busy/wait responses.
I, like you, store my mesh in EEPROM and probe outside of the plugin, but many people do not do that or have the capability to do that. For that reason I was trying to get the serial communication data from the different firmware variants to see if there was a more streamlined approach I could use in the plugin.
One possible solution I was thinking of was firmware based line processing, where if the plugin knows what firmware you are using it optimizes the process for that specific firmware. It would greatly reduce the complexity of my current line processing with extremely complicated regular expressions and allow for easier expansion/modification in the future.
I pretty much do the same as @raymondh. BLV just sends the command to return the grid data and probing is handled elsewhere. If anything I'd have BLV perform the probe routine if it were a separate button.
1 Like
Here's a G81 ("get the bed level status") from a Prusa MK3S:
Send: G81
Recv: Num X,Y: 7,7
Recv: Z search height: 5.00
Recv: Measured points:
Recv: 0.05250 0.09667 0.09833 0.13000 0.12833 0.12333 0.12083
Recv: 0.16750 0.28417 0.22667 0.17250 0.22167 0.16417 0.10583
Recv: 0.19583 0.23917 0.20000 0.18667 0.20333 0.15667 0.09000
Recv: 0.14583 0.14917 0.15250 0.17083 0.15750 0.10833 0.05667
Recv: 0.19167 0.21083 0.17917 0.16604 0.14750 0.10917 0.00000
Recv: 0.20667 0.22083 0.18667 0.16667 0.13250 0.06333 -0.04583
Recv: 0.12250 0.14417 0.15833 0.09833 0.07000 -0.00667 -0.07500
Recv: ok
Here's a G80 ("do the bed level status") from the same printer:
Send: G80
Recv: echo:Enqueing to the front: "G28 W0"
Recv: tmc2130_home_enter(axes_mask=0x01)
Recv: 0 step=14 mscnt= 225
Recv: tmc2130_goto_step 0 45 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x01
Recv: tmc2130_home_enter(axes_mask=0x02)
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: 0 step=50 mscnt= 801
Recv: tmc2130_goto_step 1 33 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x02
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: ok
and here's the M115 info:
Send: M115
Recv: FIRMWARE_NAME:Prusa-Firmware 3.8.1 based on Marlin FIRMWARE_URL:https://github.com/prusa3d/Prusa-Firmware PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa i3 MK3S EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
That's what you needed, yeah?
1 Like
https://docs.octoprint.org/en/master/plugins/hooks.html#octoprint-comm-protocol-firmware-info
^ that's the best I can offer