Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Makergear M3_ID with Marlin 1.1.6.1.1? #269

Open
atestani opened this issue Jul 6, 2020 · 41 comments · Fixed by #398
Open

Makergear M3_ID with Marlin 1.1.6.1.1? #269

atestani opened this issue Jul 6, 2020 · 41 comments · Fixed by #398
Labels
enhancement New feature or request
Milestone
1.0.1

Comments

@atestani
Copy link

atestani commented Jul 6, 2020

Does this plug-in support Makergear M3-ID (dual extruder) with Marlin 1.1.6.1.1? The M3-ID printer comes equipped with the BLTouch probe with firmware support included.

I have the plug-installed and it will do the mesh probing but no data or graph is displayed. I have tried various gcode but none seem to work. Timeout is set for the default 1800 seconds. If the plug-in should work with this firmware, what gcode should i be using?

Off topic here but may help with a solution: Another plug-in: OctoPrint-BLTouch is also installed so BLTouch controls appear on the Control tab. Clicking any button just causes a buzzing sound from the printer... nothing else. The buzzing continues until I restart OctoPrint.
@jneilliii
Copy link
Owner

The BLTouch plugin is mine as well. The only thing it does is send gcode commands configured in the plugin's settings. If you know the proper commands to send to control the BLTouch, I recommend you adjusting those settings.

As for the graphing issue, that's completely dependent on the output of the leveling command. 1.1.6.1.1 is an extremely old Marlin variant, and I do not know if that sends the report data or not. If the firmware is stock, the reporting mechanism could have been stripped out to save space. So the short answer is if it doesn't report the mesh data, this plugin will not work for you.

@atestani
Copy link
Author

atestani commented Jul 6, 2020 via email

@jneilliii
Copy link
Owner

If at the end i click the save button, can I use
that data on subsequent prints to skip the propping operation?

That's another firmware dependent question. I can't say for sure.

The Marlin version is adapted by MakerGar to run on the RamBo in the
printer.

I bet you can find current versions of Marlin that work with this. I myself have used RamBo boards for many years and the default Marlin is able to handle it without problems. The trick is knowing what's connected to which pin on the board, which the manufacturer may have tweaked in some way, so again hard to say.

@atestani
Copy link
Author

atestani commented Jul 7, 2020

I received an excellent response from MakerGear to my questions about both of the plug-ins (sorry to mix the two into one issue). They are working on Marlin and Octoprint updates. I did learn some things I will pass along.

For the BLTouch plug-in, all that is required is to change "P0" to "P1" and the basic buttons all work (except alarm). For the "Probe Bed" button, a G28 must precede the G29 or the G29 is ignored.

For the visualizer, the issue is the format of the mesh data. Marlin 1.1.6.1.1 is outputting it this way:
Recv: Bilinear Leveling Grid:
Recv: = [[ 10.000, 100.000, 190.000, 10.000, 100.000, 190.000, 10.000, 100.000, 190.000] ,[ 0.000, 0.000, 0.000, 115.000, 115.000, 115.000, 230.000, 230.000, 230.000] ,[ -0.040, -0.005, -0.146, -0.058, -0.001, -0.123, -0.014, 0.013, -0.139]];
which, apparently, the plug-in is not happy with.

@jneilliii
Copy link
Owner

Ok, just to make sure I understand, the output of the command in terminal when you run G28 followed by G29 is like this exactly?

Recv: Bilinear Leveling Grid:
Recv: = [[ 10.000, 100.000, 190.000, 10.000, 100.000, 190.000, 10.000, 100.000, 190.000] ,[ 0.000, 0.000, 0.000, 115.000, 115.000, 115.000, 230.000, 230.000, 230.000] ,[ -0.040, -0.005, -0.146, -0.058, -0.001, -0.123, -0.014, 0.013, -0.139]];

If so, I can adjust the plugin to be able to handle that I believe.

@jneilliii jneilliii added the enhancement New feature or request label Jul 7, 2020
@atestani
Copy link
Author

atestani commented Jul 7, 2020 via email •
edited by jneilliii
Loading

@jneilliii
Copy link
Owner

jneilliii commented Jul 7, 2020 •
edited
Loading 

Send: G28
Recv: echo:Active Extruder: 0
Recv: current_position[Z_AXIS] 0.00
Recv: Raise Z (before homing) to 10.00[...]
Recv: echo:Active Extruder: 0[...]
Recv: echo:enqueueing "T0"
Recv: echo:enqueueing "G29 P3"
Recv: echo:Active Extruder: 0[...]
Recv: echo:Active Extruder: 1
Recv: echo:Active Extruder: 0
Recv: X:-20.77 Y:-15.50 Z:11.08 E:0.00 Count X:-1664 Y:-1242 Z:11165
Recv: ok
Recv: echo:Active Extruder: 0[...]
Recv: Bilinear Leveling Grid:
Recv:  = [[ 10.000, 100.000,190.000, 10.000, 100.000, 190.000, 10.000, 100.000, 190.000]  ,[0.000, 0.000, 0.000, 115.000, 115.000, 115.000, 230.000, 230.000,230.000]  ,[ -0.050, 0.004, -0.150, -0.058, 0.006, -0.118, -0.023,0.008, -0.144]];
Recv: X:169.00 Y:230.00 Z:11.19 E:0.00 Count X:13537 Y:18423 Z:11165

Send: G29 T[...]
Recv: Bilinear Leveling Grid:
Recv:  = [[ 10.000,100.000, 190.000, 10.000, 100.000, 190.000, 10.000, 100.000, 190.000],[ 0.000, 0.000, 0.000, 115.000, 115.000, 115.000, 230.000, 230.000,230.000]  ,[ -0.046, 0.008, -0.146, -0.051, 0.005, -0.112, -0.018,0.014, -0.135]];
Recv: X:169.00 Y:230.00 Z:11.19 E:0.00 Count X:13537Y:18423 Z:11165

@jneilliii
Copy link
Owner

So yeah, your leveling report is very close to the scad format already supported, which is returned in multiple lines rather than just one big line like below, so I think the changes would be minimal to support it.

Recv: Mesh Bed Level data:
Recv: 6 x 6 mesh. Z offset: 0.00000
Recv: Measured points:
Recv: measured_z = [
Recv:  [ +0.200, +0.093, +0.039, -0.005, -0.048, -0.072 ],
Recv:  [ +0.176, +0.063, -0.018, -0.039, -0.048, -0.040 ],
Recv:  [ +0.178, +0.059, -0.024, -0.040, -0.054, -0.047 ],
Recv:  [ +0.206, +0.078, -0.008, -0.036, -0.064, -0.082 ],
Recv:  [ +0.243, +0.098, -0.008, -0.064, -0.127, -0.164 ],
Recv:  [ +0.249, +0.124, +0.001, -0.072, -0.159, -0.247 ]
Recv: ];
Recv: ok

@atestani
Copy link
Author

atestani commented Jul 7, 2020 via email

@atestani
Copy link
Author

Makergear verified that G28 does spawn a G29 T call.

In any case, are you updating your plug-in to accept the Marlin 1.1.6.1.1 output format and if so when do you expect to release it?

Thanks!

@jneilliii
Copy link
Owner

I have flagged this as a enhancement and will incorporate that report format. ETA as to when that happen is unknown at this time. I do have a full time job and do this on the side, so as time permits. As mentioned, I don't think it will take long to add this and may be able to get the changes squeezed in for the next release.

@jneilliii
Copy link
Owner

Hey, quick question. Do you get a response from the command M420 V that includes the mesh data as well? Is it in the same format?

@atestani
Copy link
Author

Same thing with M420 V. This was after I finished a print so the mesh data wa already available. I restarted the printer and ran G28 M420V and got the same thing. Recall on this version of MG's Marlin calling G29 returns an error message to run G28 first. H28 calls G29 T

Send: M420 V
Recv: Bilinear Leveling Grid:
Recv:  = [[ 10.000, 100.000, 190.000, 10.000, 100.000, 190.000, 10.000, 100.000, 190.000]  ,[ 0.000, 0.000, 0.000, 115.000, 115.000, 115.000, 230.000, 230.000, 230.000]  ,[ 0.294, 0.019, -0.137, -0.027, 0.018, -0.122, 0.024, 0.034, -0.132]];
Recv: echo:Bed Leveling Off
Recv: echo:Fade Height Off
Recv: ok

@jneilliii
Copy link
Owner

I think I have a working solution in my current dev branch. If you want to test it out for me and report back that would be great. Use the URL below in plugin manager > get more > ... from URL and click Install.

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

@atestani
Copy link
Author

atestani commented Jul 18, 2020 via email

@jneilliii
Copy link
Owner

Is there an ok returned just prior to the report?

@atestani
Copy link
Author

atestani commented Jul 18, 2020 via email

@jneilliii
Copy link
Owner

Would you please try the following in your gcode settings for me?

G28
@BEDLEVELVISUALIZER
M420 V

@atestani
Copy link
Author

atestani commented Jul 18, 2020 via email

@jneilliii
Copy link
Owner 

Send: G28Recv: echo:Active Extruder: 0
Recv: current_position[Z_AXIS]0.00
Recv: Raise Z (before homing) to 10.00[...]
Recv: echo:Active Extruder: 0[...]
Recv: echo:enqueueing "T0"
Recv: echo:enqueueing "G29 P3"
Recv: echo:Active Extruder: 0[...]
Recv: echo:Active Extruder:1
Recv: echo:Active Extruder: 0
Recv: X:-20.77 Y:-15.50 Z:11.08 E:0.00 Count X:-1664 Y:-1242 Z:11165
Recv: ok
Send: @BEDLEVELVISUALIZER
Send: M420 V
Recv: echo:Active Extruder: 0[...]
Recv: Bilinear Leveling Grid:
Recv:  = [[ 10.000, 100.000, 190.000, 10.000, 100.000, 190.000,10.000, 100.000, 190.000]  ,[ 0.000, 0.000, 0.000, 115.000, 115.000,115.000, 230.000, 230.000, 230.000]  ,[ -0.054, -0.028, -0.188,-0.047, 0.005, -0.138, -0.023, -0.001, -0.175]];
Recv: X:169.00 Y:230.00 Z:11.21 E:0.00 Count X:13537 Y:18423 Z:11165
Recv: echo:Unknown command: "@BEDLEVELVISUALIZER"
Recv: ok[...]
Recv: Bilinear Leveling Grid:
Recv:  = [[ 10.000, 100.000, 190.000, 10.000, 100.000,190.000, 10.000, 100.000, 190.000]  ,[ 0.000, 0.000, 0.000, 115.000,115.000, 115.000, 230.000, 230.000, 230.000]  ,[ -0.054, -0.028,-0.188, -0.047, 0.005, -0.138, -0.023, -0.001, -0.175]];
Recv: echo:Bed Leveling On
Recv: echo:Fade Height Off
Recv: ok[...]

Ok, I think I'm going to have to get your full debug log. Please enable debug logging in the plugin's settings, restart octoprint and try a mesh update. Then grab the file plugin_bedlevelvisualizer_debug.log from OctoPrint's logging section in settings and drag it here into a comment. From that I should be able to accurately re-create the pattern that your printer is reporting, because I think something might be getting jumbled during email replies.

@atestani
Copy link
Author

OK... I set the date/time on the printer RPi so of times look weird this is why. Debugging in the plugin has always been enabled but the active log looks very strange as it only shows me cancelling the mesh acquisition. I am attaching it as well as a past log that may help as it does show some mesh data
plugin_bedlevelvisualizer_debug.log
plugin_bedlevelvisualizer_debug2020-07-07.log

@jneilliii
Copy link
Owner

Weird. the way I'm debugging this on my side seems to be working so I'm a little confused unless it's the unknown command followed by ok in that communication. I'm going to try to add that to my virtual report and see if it make a difference here. The below was from what you had sent previously.

image

@atestani
Copy link
Author

Anything I can do to help? Is your virtual report generator something we MakerGear users can can use until MG updates their old Marlin firmware? If you've got the parsing for the way the report data is formatted, that would be a perfectly good solution and spare you from spending any more time to make this work!

@jneilliii
Copy link
Owner

Unfortunately, it only works with the virtual printer in OctoPrint for development. I did just push another update to the 0.1.4 branch linked below that tweaked a couple of things and might fix the problem.

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

@atestani
Copy link
Author

Still, no go. I noticed that with some scripts there wasn't an "ok" preceding the mesh report so I tried a bunch of different scripts and got some with the "ok" present. I found some other things in this Marlin version like:

  • G29 without the T still outputs a mesh report
  • G29 doesn't respect the T parameter, e.g. G29 T1
  • M420 does not respect the T parameter
  • G28 X Y Z will home as expected but G28 alone calls G29 P3 and outputs a mesh report (known previously)

I am attaching 8 terminal logs in case you are interested. You can see the various commands from the script I used.

However, while I sincerely appreciate your efforts to make this work, IMHO, I don't think it is worth the time you are spending on it given the age of this Marlin version. At this point, you may be doing it because it is simply bugging you ( I do lots of code myself and know about this "problem") so I will continue to run any tests or provide data as long as you want.

I understand about the virtual report/printer, etc. but here is another (possibly bad) idea. Do you have some Python and/or javascript/Plotly code that can be put together to allow the manual entry of the mesh data to get the visualization? That would be great for the current issue and anyone else having similar problems.

Thanks again.

run 1.txt
run 2.txt
run 3.txt
run 4.txt
run 5.txt
run 6.txt
run 7.txt
run 8.txt

@jneilliii
Copy link
Owner

Do you have some Python and/or javascript/Plotly code that can be put together to allow the manual entry of the mesh data to get the visualization? That would be great for the current issue and anyone else having similar problems.

I don't. What I typically do is re-create the communication with the virtual printer, for example your communication is here. I was using the to mimic your printer, but apparently for some reason it's not directly comparing to real world.

@jneilliii
Copy link
Owner

M420 does not respect the T parameter

M420 has a V parameter typically.

@atestani
Copy link
Author

atestani commented Jul 19, 2020 via email

@atestani
Copy link
Author

atestani commented Jul 19, 2020 via email

@jneilliii
Copy link
Owner

Ok, so the current workflow is that the plugin monitors the @ commands being sent to your printer. If it detects the custom command @BEDLEVELVISUALIZER it flags a boolean True to instruct the gcode receiving hook to start monitoring the serial communication in this callback. Then as lines are received the gcode processing hook compares those received lines against several different regular expressions, in your case the one that I added here. If that match occurs then it is recorded here. That data is converted into a list using json.loads, and then when the next ok comes through the final processing occurs and the data is sent back to the front end here.

@atestani
Copy link
Author

atestani commented Jul 19, 2020 via email

@jneilliii
Copy link
Owner

The mesh wouldn't be collected yet at that point in time I don't think so the len condition would fail anyway.

@jneilliii jneilliii added this to the 0.1.15 milestone Jul 26, 2020
@jneilliii jneilliii modified the milestones: 0.1.15, 0.1.16 Oct 3, 2020
@jneilliii jneilliii modified the milestones: 1.0.0, 1.0.1 Nov 12, 2020
@jneilliii jneilliii modified the milestones: 1.0.1, 1.0.2 Jan 13, 2021
@jneilliii
Copy link
Owner

This issue may be resolved with my most recent release candidate of the plugin. It accounts for numbers that start with one more than one digit before the decimal point, which I think might have been the underlying issue here. If you want to try it out, you can caopy/paste the URL below into plugin manager > get more > ...from URL and clicking Install.

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

@jneilliii jneilliii modified the milestones: 1.0.2, 1.0.1 Jan 13, 2021
@jneilliii jneilliii added the solved workaround documented or fix applied label Jan 13, 2021
@atestani
Copy link
Author

atestani commented Jan 13, 2021 via email

@jneilliii jneilliii removed the solved workaround documented or fix applied label Jan 13, 2021
@jneilliii
Copy link
Owner

Ok, thanks. I think I see now that my previous changes wouldn't resolve this. I need to create a custom regex parser for this output. Best I can tell from this format, it's an array containing the x points, y points, and z offsets.

= [[ 10.000, 100.000, 190.000, 10.000, 100.000, 190.000,
10.000, 100.000, 190.000]  ,[ 0.000, 0.000, 0.000, 115.000, 115.000,
115.000, 230.000, 230.000, 230.000]  ,[ -0.059, -0.057, -0.191,
-0.040, 0.003, -0.126, -0.030, -0.031, -0.175]]

@atestani
Copy link
Author

atestani commented Jan 13, 2021 via email

@jneilliii jneilliii mentioned this issue Feb 28, 2021
Merged
jneilliii added a commit that referenced this issue Feb 28, 2021
@jneilliii
1.0.1 (#398)
7028ea2 
**Added**
* optional timeout override to @BEDLEVELVISUALIZER command, #314
* settings button on tab for quick access, #349

**Updated**
* README.md adding note that auto bed leveling must be possible on printer, #348

**Fixed**
* allow for probe points that contain more than single digits, #352, #269
* resolve issues with circular beds
@atestani
Copy link
Author

atestani commented Mar 2, 2021 via email

@jneilliii
Copy link
Owner

Oh sorry, this got closed inadvertently.

@jneilliii jneilliii reopened this Mar 2, 2021
@atestani
Copy link
Author

atestani commented Mar 2, 2021 via email

@jneilliii
Copy link
Owner

Actually looking back at the code, this might be fixed. Have you tried with 1.0.1 yet?

@atestani
Copy link
Author

atestani commented Mar 19, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
1.0.1
Development

Successfully merging a pull request may close this issue.

1.0.1 jneilliii/OctoPrint-BedLevelVisualizer
2 participants
@atestani @jneilliii