Add support for Prusa MINI, Marlin and arbitrary mesh grid sizes

[acortelyou]

Resolves issues #11, #12, and probably #27.

[scottrini]

Oh wow, hey, this looks great! I should be able to make some time tomorrow to spin this up on my mini and give it a thorough test. This is something I'd been meaning to get around to, but hadn't had the time. So thanks for contributing!

[acortelyou]

@scottrini I was doing some additional testing and realized that marlin/mini style responses have the Y reversed compared to the i3 firmware, so I tweaked the regex to be able to differentiate and handle the cases separately.

[scottrini]

So I've been playing with this recently and first I was testing on my MK3S's since I wanted to make sure previously functionality was still fine. Once I got it installed on them successfully, everything seems fine and good to go. On the other hand, I'm still fighting with getting it on my mini's pi, but I wanted to post already because I wanted to discuss the new dependencies...I normally have no issues adding dependencies, but because I had issues on all the pi's I've tested with so far, it gives me some concern.

3 pi's connected to MK3S's, all running python 3 had the same issue - I'd uninstall the current version of the plugin and install from a zip of your branch and octoprint would install "Unknown." Found the error in the logs and figured out I had to ssh in and run sudo apt-get install libatlas-base-dev.

For the mini, it's an old pi 2 running python 2.x. So this has been a whole other set of problems - I've been fighting with it to get scipy installed, but I think I'm close, but I've had to resort to doing all of this from a shell instead of through octoprint.

So my concern is obviously how this will roll out for existing users. I worry once they get notified of an upgrade, they'll see similar issues trying to upgrade and there's a lot of people who won't want to connect via ssh to install a package.

So any ideas how to make sure we don't see anything like this if we roll it out?

[acortelyou]

Do you know what version of OctoPi you were running?

According to rando-forum guy that package should be pre-installed since OctoPi 0.18 (25 Jan 21).

I can confirm I had to do the same as you on OctoPi 0.17/1.5.3/2.7.16, but the dependencies installed automatically without complaint under OctoPrint 1.5.3/3.8.5 on ubuntu with no need for apt.

I'm going to backup the testing pi, flash 0.18 and restore to see what happens there.

Not 100% sure what the best path forward is yet as these aren't obscure or uncommon dependencies and it appears to be a platform issue not a problem with the plugin itself.

[acortelyou]

Confirmed: On OctoPi 0.18 the plugin installs successfully without intervention, and after switching the gcode to use G29 the leveling guidance worked as expected with the Prusa MINI.

I don't have a Mk3s to test myself but I mocked one with the virtual printer and that worked too.

I guess there are a few options to consider: Documenting how to install scipy dependencies brightly+clearly, marking it as compatible with >=0.18, release channels...

[jneilliii]

I fought to get libatlas-base-dev included with octopi 0.18 to handle issues related to installing numpy in python 3 environment that ships with that version, but I still ended up having to put that into the known issues section of the plugin to handle people that upgraded their python environment too.

[scottrini]

I was actually able to re-test today. I upgraded the pi my mini was on to a 3 and used a fresh octopi 0.18, so I was able to confirm the same - installed without a problem and was able to get it running on the mini (which illustrated how much I need to apply the nylock mod to mine).

So I think I'll end up merging and just adding a note to the README.md when I bump/tag and cut the release. It's still something that I'm sure will come up for others, so I hope I can get it documented clearly enough going forward.

[acortelyou]

Awesome!