Comments (14)
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.
from tweaker-3.
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.
from tweaker-3.
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 removalclass 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?
from tweaker-3.
I haven't forgot about this. I have it on my TODO-list and it is unfortunately planned to be done end of February.
from tweaker-3.
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?
from tweaker-3.
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 :)
from tweaker-3.
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
from tweaker-3.
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! šŖ
from tweaker-3.
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?
from tweaker-3.
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!
from tweaker-3.
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.
from tweaker-3.
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.
from tweaker-3.
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?
from tweaker-3.
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?
from tweaker-3.
Related Issues (20)
- Question: Is there a way to minimize support, assuming support is only generated "from buildplate/bed"? HOT 3
- AttributeError: 'Tweak' object has no attribute 'ANGLE_SCALE' HOT 1
- Favorite side function documentation HOT 2
- Kind of wrong placement HOT 2
- 3mf with multiple objects HOT 3
- Questions about porting Tweaker-3; question about death star algorithm HOT 4
- Still in development? HOT 6
- NOT AN ISSUE: Suggestion
- Query Not an Issue HOT 2
- Cura Plugin HOT 1
- Model in ASCII .stl can't be tweaked, but same model in binary .stl works
- Pip installation error. HOT 2
- os.system('cls') is Windows only
- #notabug Do you have use cases pictures? HOT 2
- I downloaded it, but I ca nāt use it Cura2.5
- Unavailable after installation. cura15&cura 2.7 HOT 4
- SyntaxError: invalid syntax w/ demo.stl HOT 1
- High Memory Usage HOT 3
- Broken Facet Count HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tweaker-3.