Lerdge Firmware Support

[CodingMush]

good day everybody,
your plugin looks good and I would like to use it with my Lerdge board. Unfortunately, I have not yet received results because the Lerdge firmware uses a different output format.
Could you include support for Lerdge?

Thank you and best regards

Send: G29
Recv: echo: The system is homing, please wait...
Recv: echo: The system starts to level automatically, please wait for finishing the leveling
Recv: (0,0,-2.661)  (1,0,-2.738)  (2,0,-2.861)  (3,0,-2.775)
Recv: (3,1,-2.831)  (2,1,-2.900)  (1,1,-2.845)  (0,1,-2.780)
Recv: (0,2,-2.790)  (1,2,-2.830)  (2,2,-3.388)  (3,2,-2.851)
Recv: (3,3,-2.721)  (2,3,-2.804)  (1,3,-2.745)  (0,3,-2.720)
Recv: ok

[jneilliii]

Thanks for the detailed terminal information. That will help in adding support for your firmware. I'll see what I can do when I have some spare time.

[Yersi88]

Was there any progress on this feature? I would appreciate support for Lerdge board too :)

EDIT: Also board spits out all the data when it's finished at once.

I'm adding my output:
Send: G29
Recv: echo: The system is homing, please wait...
Recv: echo: The system starts to level automatically, please wait for finishing the leveling
Recv: (0,0,0.313) (1,0,0.273) (2,0,0.152) (3,0,0.035) (4,0,-0.056) (5,0,-0.177) (6,0,-0.333) (7,0,-0.530) (8,0,-0.697) (9,0,-0.899)
Recv: (9,1,-0.818) (8,1,-0.652) (7,1,-0.449) (6,1,-0.253) (5,1,-0.121) (4,1,-0.010) (3,1,0.106) (2,1,0.197) (1,1,0.313) (0,1,0.323)
Recv: (0,2,0.359) (1,2,0.313) (2,2,0.202) (3,2,0.081) (4,2,0.025) (5,2,-0.086) (6,2,-0.207) (7,2,-0.404) (8,2,-0.576) (9,2,-0.808)
Recv: (9,3,-0.737) (8,3,-0.566) (7,3,-0.369) (6,3,-0.202) (5,3,-0.045) (4,3,0.035) (3,3,0.111) (2,3,0.227) (1,3,0.308) (0,3,0.323)
Recv: (0,4,0.278) (1,4,0.268) (2,4,0.157) (3,4,0.071) (4,4,0.025) (5,4,-0.086) (6,4,-0.172) (7,4,-0.369) (8,4,-0.500) (9,4,-0.727)
Recv: (9,5,-0.692) (8,5,-0.520) (7,5,-0.369) (6,5,-0.207) (5,5,-0.086) (4,5,0.000) (3,5,0.071) (2,5,0.121) (1,5,0.192) (0,5,0.192)
Recv: (0,6,0.111) (1,6,0.101) (2,6,0.030) (3,6,-0.020) (4,6,-0.076) (5,6,-0.162) (6,6,-0.258) (7,6,-0.394) (8,6,-0.525) (9,6,-0.702)
Recv: (9,7,-0.697) (8,7,-0.551) (7,7,-0.439) (6,7,-0.318) (5,7,-0.212) (4,7,-0.131) (3,7,-0.091) (2,7,-0.066) (1,7,-0.010) (0,7,-0.045)
Recv: (0,8,-0.096) (1,8,-0.071) (2,8,-0.121) (3,8,-0.162) (4,8,-0.202) (5,8,-0.278) (6,8,-0.359) (7,8,-0.495) (8,8,-0.601) (9,8,-0.712)
Recv: (9,9,-0.702) (8,9,-0.566) (7,9,-0.455) (6,9,-0.333) (5,9,-0.253) (4,9,-0.187) (3,9,-0.157) (2,9,-0.126) (1,9,-0.071) (0,9,-0.106)
Recv: ok

[jneilliii]

I have not made any progress on this report format and currently work is being done on removing the numpy dependency in the plugin, so I'd rather wait until that is completed until I attempt to incorporate support for other firmware.

[chrisper0815]

Hi,
lerdge auto level now look like that:

Recv: echo: The system is homing, please wait...
Recv: echo: The system starts to level automatically, please wait for finishing the leveling
Recv: 0(0.000,0.000,0.078) 1(112.500,0.000,0.236) 2(225.000,0.000,0.394)
Recv: 3(0.000,112.500,-0.045) 4(112.500,112.500,0.002) 5(225.000,112.500,0.138)
Recv: 6(0.000,225.000,-0.280) 7(112.500,225.000,0.022) 8(225.000,225.000,0.044)
Recv: ok

It would be great to include this in an update.
THX, Chris

[jneilliii]

ugh...why did they change that, just makes it more difficult to integrate. Could you guys give me firmware version numbers?

[Elarion245]

New format still applicable with firmware 4.6.0

[jneilliii]

Initial support for lerdge firmware is added in the above commit and available as part of version 1.1.2rc8. You can switch the release channel in OctoPrint's Software Update settings for the plugin to Release Candidate and update when prompted.

This change assumes that the line echo: The system starts to level automatically, please wait for finishing the leveling is returned from the firmware prior to reporting mesh data.

The below graph was generated from the data provided by #167 (comment)

[jneilliii]

The change doesn't yet extract the x/y value from the report the way it should and is using the interpreted method of dividing the bed size by number of points like in other firmware. That is something that I'd like to change in the future.

[Elarion245]

Thank you so much for working on this!!
I tried it this morning, but I wasn't successful. This is my terminal output (I uncommented the EEPROM save):

Send: M140 S60
Recv: ok
Send: G28
Recv: echo:  The system is homing, please wait...
Recv: ok
Send: M190 S60
Recv: ok
Send: G29 T
Recv: echo:  The system is homing, please wait...
Recv: echo:  The system starts to level automatically, please wait for finishing the leveling
Recv: 0(0.000,0.000,-0.310)  1(56.667,0.000,-0.415)  2(113.333,0.000,-0.560)  3(170.000,0.000,-0.481)
Recv: 4(0.000,56.667,-0.570)  5(56.667,56.667,-0.609)  6(113.333,56.667,-0.662)  7(170.000,56.667,-0.652)
Recv: 8(0.000,113.333,-0.881)  9(56.667,113.333,-0.965)  10(113.333,113.333,-0.955)  11(170.000,113.333,-0.928)
Recv: 12(0.000,170.000,-1.266)  13(56.667,170.000,-1.321)  14(113.333,170.000,-1.304)  15(170.000,170.000,-1.263)
Recv: ok
Send: #M500
Send: M300 S440 P200
Recv: ok
Send: M140 S0
Recv: ok

Visualization stuck on: "Please wait, retrieving current mesh."
The only difference I see with respect to the test data in above post, it that I find two space characters prior each leveling point and the message "The system starts to...". Checking the diff in you commit, it seems that only one is assumed.

[jneilliii]

Yeah, the previous report from Nov 2022 only had a single space. I can adjust that to be a little more generic.

[jneilliii]

new release 1.1.2rc9 is out now with those adjustments, you can force check for updates from the pull down on the check for updates button in software update settings.

[Elarion245]

Awesome. Will check right after my currently runing print is finished (1h left) and report back. Thanks again!

Edit: Somehow my Octo seems to think that 1.1.2rc8 is still the most recent, despite forcing it. Also in the release overview rc9 is below rc8. What am I missing?

[Elarion245]

plugin_bedlevelvisualizer_debug.log
Could it be that you tagged the wrong commit with rc9?

Edit: OK, managed to find the right commit and to install it manually via file upload. Sadly the behavior hasn't changed.
Output from terminal (don't mind about the difference in the z data, I reassembled the printhead and bed today):

Send: M190 S60
Recv: ok
Send: G29 T
Recv: echo:  The system is homing, please wait...
Recv: echo:  The system starts to level automatically, please wait for finishing the leveling
Recv: 0(0.000,0.000,-1.265)  1(56.667,0.000,-1.300)  2(113.333,0.000,-1.311)  3(170.000,0.000,-1.278)
Recv: 4(0.000,56.667,-1.457)  5(56.667,56.667,-1.420)  6(113.333,56.667,-1.493)  7(170.000,56.667,-1.570)
Recv: 8(0.000,113.333,-1.736)  9(56.667,113.333,-1.795)  10(113.333,113.333,-1.872)  11(170.000,113.333,-1.818)
Recv: 12(0.000,170.000,-2.087)  13(56.667,170.000,-2.170)  14(113.333,170.000,-2.192)  15(170.000,170.000,-2.202)
Recv: ok
Send: M300 S440 P200
Recv: ok

I manually added two logs to the plugin and then reuploaded the zip:

			elif "The system starts to level automatically, please wait for finishing the leveling" in line.strip():
				self._bedlevelvisualizer_logger.debug("Activating Lerdge")
				self.lerdge_firmware = True

The log in fact shows:

[2024-01-28 19:00:48,045] DEBUG: mesh collection started
[2024-01-28 19:00:56,550] DEBUG: mesh collection started
[2024-01-28 19:01:03,722] DEBUG: Activating Lerdge

The second line I added is the following:

				if self.lerdge_firmware:
					self._bedlevelvisualizer_logger.debug("Starting lerdge extraction")
					new_line = self.regex_lerdge_extraction.findall(line)

The logfile however never reports the "Starting lerdge extraction".

Edit2:
After adding few more log files, it seems that the following if is failing:

			self._bedlevelvisualizer_logger.debug("line is: "+line)
			if self.regex_mesh_data.match(line.strip()):
				self._bedlevelvisualizer_logger.debug("line strip")

The corresponding log never shots the "line strip" message:

[2024-01-28 19:18:09,876] DEBUG: line is: 0(0.000,0.000,-1.195)  1(56.667,0.000,-1.265)  2(113.333,0.000,-1.324)  3(170.000,0.000,-1.292)

[2024-01-28 19:18:09,885] DEBUG: line is: 4(0.000,56.667,-1.407)  5(56.667,56.667,-1.410)  6(113.333,56.667,-1.515)  7(170.000,56.667,-1.557)

[2024-01-28 19:18:09,893] DEBUG: line is: 8(0.000,113.333,-1.685)  9(56.667,113.333,-1.817)  10(113.333,113.333,-1.860)  11(170.000,113.333,-1.834)

[2024-01-28 19:18:09,900] DEBUG: line is: 12(0.000,170.000,-2.105)  13(56.667,170.000,-2.225)  14(113.333,170.000,-2.216)  15(170.000,170.000,-2.209)

I see that the regex_mesh_data was also part of the lerdge rc8 upgrade. It seems that the last blocker is somewhere in this regex.

[jneilliii]

yeah, was just doing the same. I see the issue. your report added additional spaces between the numbers too so had to adjust the overall regex for that. new release about to come out.

[Elarion245]

It works!! Damn this is beautiful!
Thank you so much!

[jneilliii]

recommend setting the relative z offset option in your case to pull the mesh up closer to 0.