Request: support for off-axis belt printers about tweaker-3

[smartin015]

This use-case is quite specific to this printer. I think this argument is too specific to be integrated into the main branch.

FWIW, there are currently four other printers on the market that are belt-based, likely with more on the way as I believe the original patent had aged out a year or two ago.

However, I can make the changes for a fee. If you are interested contact me on [email protected]

I'm sadly not in a position to support this change financially, so I think I'll just create a fork and noodle on this feature in my own time (with adherence to GPL3). I can sync back here with a summary of changes if you'd like to pick and choose potential contributions back to the main branch.

[ChristophSchranz]

Hi @smartin015,
that are good points! I have also planned a bigger refactoring and unit tests, but had unfortunately no time yet..

So I'm open to this refactoring. Could you make a new branch called "dev" or something similar in which we collect the bigger refactoring and tests? I think it makes sense to combine our ideas and then merge it into main.

[smartin015]

I found myself doing a little bit of refactoring and writing some unit tests in an attempt to better understand how everything fits together. You can take a look at the WIP here.

I'm finding the single class Tweak becomes even more readable when split out into

• class Orientation, handling orientation vectors/weights, supplemental generation, and duplicate orientation removal
• class Mesh, handling mesh loading/annotation, death star, area cumulation, vertex projection etc.
• class Tweak, all the original behavior not captured above (target function, unprintability, actually performing the tweak etc.)

Unit tests become a lot easier to write in this way, and performance should be roughly the same.

I also started assigning const class vars (e.g. M.NORM) representing indices of various indices of interest in the mesh Nx6x3 matrix, so I don't have to remember that mesh[:, 0, :] represents the normal vector, mesh[:, 5, 0] the area, etc. when reading through the code.

@ChristophSchranz would you accept a PR with this refactor and some accompanying unit tests, if I can demonstrate correct behavior and similar performance?

[ChristophSchranz]

I haven't forgot about this. I have it on my TODO-list and it is unfortunately planned to be done end of February.

[smartin015]

After a bit of browsing... I'm really impressed that Tweak is a single class that can be reasonably understood from source code. Only sticky part is the mesh data structure... did I read it correctly as something like face_count * [norm.xyz, v0.xyz, v1.xyz, v2.xyz, (v0.z, v1.z, v2.z), (area_size, max_z, median_z)]?

Looks like if I were to patch in this kind of support, I'd need to call calc_overhang twice - once with the "real" candidate orientation, and once more with an orientation rotated by 45 degrees to simulate the angled printing of the belt printer. I'd replace the overhang results of the former with the latter.

For leading edge calculation, perhaps I can further filter contours to find the points with minimum Y-value and compute the edge lengths there.

@ChristophSchranz does that seem sensible to you? Do you have any suggestions / pointers?

If you're open to PRs, how would you recommend exposing something like this? An extra --belt argument?

[smartin015]

Hey @ChristophSchranz - I'm still interested in making this change. In fact, I'm forging ahead with auto-slicing for regular printers in my queue plugin, since PrePrintService already integrates with Tweaker and it's not that much extra code. But that just makes me want belt printer support even more, so it works with my own setup :)

[ChristophSchranz]

Hey @smartin015
I'm sorry I didn't respond!

Can I use Tweaker to account for these things? If not, what would it take to support this use case?

In the current form, this is not possible. The Tweaker is currently not sensible to the rotation around the vertical z-axis, but it certainly has to for this (IMHO cool) printer. I thought about a solution for a while. Each orientation candidate would has to find some z-axis rotation candidates. Then, the 45°-sided overhang can be calculated only with some adaptation.

This use-case is quite specific to this printer. I think this argument is too specific to be integrated into the main branch. However, I can make the changes for a fee. If you are interested contact me on [email protected]

Best,
Chris

[AlbertMN]

I think @smartin015 has a point; it's not so unique anymore - more and more belt-printers hit the market every year, and printing at weird angles is done with robot arms, welding and such as well (although a bit more complex at times, with varying angles).

If this change is made, I think it'd make perfect sense to have in main prod.

Can't speak for how complicated it is to do of course - hope you succeed @smartin015! 💪

[smartin015]

Sounds great! I also empathize with little free time... one project always borrows time from another, hence the 5 month gap in this issue :)

Just to make sure I fully understood re: the review flow - I made smartin015#1 as a little starter PR that targets a dev branch on my fork and also invited you to the fork so you can review before I merge.

Once my dev has changes vs your master, I'll open a longer-lived PR where we can discuss when to merge changes from dev to master.

So the whole review pipeline would look like

smartin015/Tweaker-3/<pr_branch> --> smartin015/Tweaker-3/dev --> ChristophSchranz/Tweaker-3/master

Does that make sense? Or would you rather create a dev branch on your repo that I can point my PRs to?

[ChristophSchranz]

Hi @smartin015, yes that sounds good. If everything is okay the functionality can be integrated.

An important aspect is that the additional function is modular, i.e., the main routine and the documentation only is extended by few lines. This will make the maintenance of the code much simpler!

[smartin015]

An important aspect is that the additional function is modular, i.e., the main routine and the documentation only is extended by few lines. This will make the maintenance of the code much simpler!

Agreed! However it may take a few PRs to get to a point where it can be added in a modular way.

Could you please take a look at smartin015#1 when you get an opportunity? If it looks good, leave a comment - I'll merge it to my dev and open a new PR to your master with a dev plan we can discuss there.

[smartin015]

Hey @ChristophSchranz - just wanted to check in and see if you'll have some time to collaborate on this in the coming weeks.

I'm still invested in making progress on this, so I can further automate my belt printing setup.

[ChristophSchranz]

Hi @smartin015,
I'll currently spend time on an update of the Octoprint Plugin and will have some time for this from May on. Is that okay for you?
How do you want to proceed on this?

[smartin015]

Hey @ChristophSchranz,

Yep, happy to proceed at your pace. I'd like to start off by submitting a few cleanup PRs without changing much of the original functionality, in preparation for adding belt printing support.

A good start would be reviewing my smartin015#1 from December. But in hindsight, I think it'd be best if you created a dev branch in your repository, rather than the current target of a branch in my fork. If you create the branch, I could retarget that PR and make the review/merge process more direct. WDYT?