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.

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

Support wipe-to-object and wipe-to-infill #1

Open
vintagepc opened this issue Jan 20, 2020 · 5 comments
Open

Support wipe-to-object and wipe-to-infill #1

vintagepc opened this issue Jan 20, 2020 · 5 comments
Assignees
Labels
Blocked Issue cannot be worked on until something else happens. enhancement New feature or request scheduled Issue is planned to be addressed.

Comments

@vintagepc
Copy link
Owner

I had to disable/remove the wipe options to get this working initially. Figure out how to re-implement those; it'll be tricky since you no longer have the purge volumes available to calculate from the tower, and they can be tricky to determine based on the object, owing to Plicer isssue 2855 (prusa3d/PrusaSlicer#2855)

@vintagepc vintagepc added the enhancement New feature or request label Jan 20, 2020
@vintagepc vintagepc self-assigned this Jan 20, 2020
@bynnek
Copy link

bynnek commented Jan 22, 2020

In the old script on gitlab, you left the purge tower active but moved it off the bed basically correct so you could get these volumes? Was the reason you ditched that method in the new script because it was painful to put a wipe tower out off the bed?

Couldn't the prints technically overlap with the wipe tower in PSlicer and you still extract them from the gcode later? I thought it the tower code is pretty clearly remarked in the gcode at the start and end with the "CP EMPTY GRID" or "CP TOOL CHANGE START (end END)". When you arrange your print bed and put the wipe tower overlapping with your actual parts, it'll try to physically print them both in the same space even though they will interfere.

@vintagepc
Copy link
Owner Author

Complexity. I wanted to greatly simplify a lot of the handling, this old code comprised a good chunk of the code and it was not maintainable (at some point between 2.0 and 2.2, it broke and I didn't get very far at locating the issue. I'd rather strip it out and rewrite that path if I have to (there are some other options for volumes - I may just submit a PR to the plicer project for the 2.20 release to get access to the volumes directly). than continually chase bugs in it as the upstream project changes the output format.

@vintagepc
Copy link
Owner Author

vintagepc commented Jan 26, 2020

I've filed a pair of upstream pull requests to expose the needed purge volume as part of the custom toolchange gcode. If those are approved it will mean we can do this without needing to resort back to enabling the WT and stripping it out.

Marking as scheduled, since it will require (hopefully) PS 2.2 for the capability.

@vintagepc vintagepc added the scheduled Issue is planned to be addressed. label Jan 26, 2020
@bynnek
Copy link

bynnek commented Jan 26, 2020

That would be rad! Is there a ticket somewhere I can go chime in on to try to pressure them?

@vintagepc
Copy link
Owner Author

Sure, you can watch them here:

prusa3d/PrusaSlicer#3550
prusa3d/PrusaSlicer#3534

and associated PRs:
prusa3d/PrusaSlicer#3573
prusa3d/PrusaSlicer#3576

@vintagepc vintagepc added the Blocked Issue cannot be worked on until something else happens. label Feb 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocked Issue cannot be worked on until something else happens. enhancement New feature or request scheduled Issue is planned to be addressed.
Projects
None yet
Development

No branches or pull requests

2 participants