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

Feature Request: Have Slic3r make a move inwards before leaving island. #186

Closed
ahmetcemturan opened this Issue Jan 31, 2012 · 19 comments

Comments

Projects
None yet
8 participants
@ahmetcemturan
Copy link

ahmetcemturan commented Jan 31, 2012

The idea is to have the nozzle make a move onto the infill of the part while or after retracting, before leaving the island or making a Z- move. It would then also land not on a perimeter but on an area of the infill (that is more tolerant to faults obviously) counter-retract and then move to the actual point of print.
That way all the ooze and blobbing would be hidden inside the perimeters...
A move 30degrees offset and 2-3 mm would be sufficient..

@cakeller98

This comment has been minimized.

Copy link
Contributor

cakeller98 commented Feb 1, 2012

Sounds good to me as well. have it do it's less than ideal bits within less important regions.

@alranel

This comment has been minimized.

Copy link
Member

alranel commented Feb 1, 2012

Yeah, we talked about this earlier and I believe it's a good idea.

@armyofevilrobots

This comment has been minimized.

Copy link

armyofevilrobots commented Feb 1, 2012

An extension to this: currently perimeters start on the inside and gradually work their way outside. This as a benefit of producing much smoother exterior surfaces since the head (kinda) smoothly ramps into the final shell, preventing a visible blob. Unfortunately holes start from the inside as well, producing a blob on the inside of a hole that often needs to be cleaned up with a drill or file, etc. to make the part usable (ie; for a mounting hole). I would like to propose the following:

  1. Holes inside of islands are extruded in order of decreasing radius, ie; surface last just like exterior walls
  2. Ramping moves (45 instead of 90 degrees, or arcs if supported) between subsequent layers in order to reduce acceleration: currently the 90 degree moves mean a full stop/start on x/y, which means hard acceleration and vibration at the extruder head, which leads to a bit of rippling on the exterior of the part.
  3. Initial extrusion optionally ramping into position, ie: start the extrude inside the island by a millimeter or so, and ramp into the perimeter as per #2. This will prevent a blob on the edge that causes deformation on subsequent layers.

Sorry if this should be in a separate ticket, but it is all related.

p.s. Thanks for multithreading!

@ahmetcemturan

This comment has been minimized.

Copy link
Author

ahmetcemturan commented Feb 1, 2012

I had tried to print a cylinder and modified its gcode. I had it
extend 3mm and change direction about 30 degrees. That way the
printer wouldnt slow down.
If it will not move to an other island (like in a z move) it should
maybe make a loop of 6-9mm diameter to arrive at the point where it
left. Preferably having completed its z move in the time....

The distances could also be multiple of the extrusion width.

@alranel

This comment has been minimized.

Copy link
Member

alranel commented Oct 28, 2012

Done! It only applies to external perimeters. I used a 45° angle and a length equal to one flow spacing.

alranel added a commit that referenced this issue Nov 29, 2012

Revert "Experimental feature: make a little move inwards by 45° after…
… finishing the external perimeter and before retracting. #186"

This reverts commit c57e94c.

Conflicts:

	lib/Slic3r/GCode.pm
@simonkuehling

This comment has been minimized.

Copy link

simonkuehling commented Dec 4, 2012

@alexrj: Oh no! I really liked that one - it provided beautifully smooth surfaces without blobs anywhere... At least for me...
Is there a particular reason for reverting this? I'd love to help troubleshoot any issues as always.

@alranel

This comment has been minimized.

Copy link
Member

alranel commented Dec 4, 2012

@simonkuehling, the implementation didn't take into account some edge (but not so rare) cases. For example, imagine a rectangular perimeter whose first (and last) point is on a corner. Since the 30° move is calculated from the direction of the last segment, it will go outside the object making a string outwards.
I need to reimplement this better.

@simonkuehling

This comment has been minimized.

Copy link

simonkuehling commented Dec 4, 2012

@alexrj: Ah, ok - great news that the feature itself isn't dismissed :-)

What if you just use, say 2/3 of the angle between the last and the next (=first) segment of the perimeter? This should ensure to stay inside the perimeter-polygon...

@alranel

This comment has been minimized.

Copy link
Member

alranel commented Dec 4, 2012

@simonkuehling, I like that idea :-)

@jmgiacalone

This comment has been minimized.

Copy link

jmgiacalone commented Dec 4, 2012

I have implemented this in my fork of Slic3r here https://github.com/emaker/slic3r/tree/dev

When an outer perimeter is preceded by an inner perimeter, the retract takes place whilst moving from the last point of the outer perimeter, towards the start point of the inner perimeter, over a distance of one extrusion width. I had to implement a new extrusion role EXTR_ROLE_HOLE for the innermost perimeter of holes, so the retract_pos is calculated when EXTR_ROLE_CONTOUR_INTERNAL_PERIMETER is followed by EXTR_ROLE_HOLE and when EXTR_ROLE_PERIMETER is followed by EXTR_ROLE_EXTERNAL_PERIMETER.

When printing with only one shell, the inwards move is not made.

Setting an angle based only on the last and first segment of the outer perimeter will not always work, since the point may be at a convex or concave corner of the polygon.

I haven't publicised my solution as I have a small issue with my code, related to a bug in clip_end() which appears to clip a polygon when working with its points, but then does not carry over when dealing with it as lines, so the end point remains unchanged, but an extra point is added at the clip distance from the end of the polygon.

All of the above is ignored when printing perimeters from outside -> in, which I have added as a GUI option too.

@nophead

This comment has been minimized.

Copy link

nophead commented Dec 4, 2012

In my own host software (which takes just the geometry from skeinforge and does the rest) after retracting at the end of an outline I move off 1mm following the outline, i.e. 1mm along the start of the outline. I find that closes the loop nicely.

@simonkuehling

This comment has been minimized.

Copy link

simonkuehling commented Dec 4, 2012

@jmgiacalone, could you explain your statement on concav/convex corners, please? i don't get it just now... quite possible that i miss something here though :-)
To my mind there is no case where the calculation of an intermediate angle could fail - provided that you choose the right side of both segments, namely the one on the inside of our polygon

@jmgiacalone

This comment has been minimized.

Copy link

jmgiacalone commented Dec 4, 2012

@simonkuehling if the code can work out which side to move, then there is no issue, but when I tried implementing such logic I couldn't see an clean way to code it. So moving to the start of the inner loop seemed an obvious solution.

@thecrazy

This comment has been minimized.

Copy link

thecrazy commented Dec 4, 2012

@nophead are you saying this closes the tiny gaps we can see were each layer perimeter start and end?

@nophead

This comment has been minimized.

Copy link

nophead commented Dec 4, 2012

Yes, but I have never tried it with slic3r as my host is Skeinforge
specific.

On 4 December 2012 21:28, Frederic Defoy notifications@github.com wrote:

@nophead https://github.com/nophead are you saying this closes the tiny
gaps we can see were each layer perimeter start and end?


Reply to this email directly or view it on GitHubhttps://github.com//issues/186#issuecomment-11016475.

@simonkuehling

This comment has been minimized.

Copy link

simonkuehling commented Dec 5, 2012

@jmgiacalone, now i get that, right. i didn't check the code - but i think alessandro already implemented the lines to choose the right side since he needs to know that with that experimental fixds angle of 30° as well

@nophead, your suggestion sounds promising, too - and is even simpler to implement. Maybe worth a try!

@alranel

This comment has been minimized.

Copy link
Member

alranel commented Dec 5, 2012

@nophead, we're dealing with a slightly different matter here. The inwards move is done before retraction, and part of its purpose is to hide the point where retraction happens.

@nophead

This comment has been minimized.

Copy link

nophead commented Dec 5, 2012

Yes but the retraction is very fast, however the plastic flow doesn't stop
instantly. I find I get a little peek in the direction I move off in. If I
follow the outline for 1mm at move speed before going off to the next
island I find I get perfect join and the nozzle is wiped so makes a clean
start when it arrives at the next island.

However I don't do outlines faster than 25mm/s or use Bowden, so I expect
things are different at crazy speeds. One of the reasons why I think
machine control and slicing should be separate programs.

On 5 December 2012 09:27, Alessandro Ranellucci notifications@github.comwrote:

@nophead https://github.com/nophead, we're dealing with a slightly
different matter here. The inwards move is done before retraction, and
part of its purpose is to hide the point where retraction happens.


Reply to this email directly or view it on GitHubhttps://github.com//issues/186#issuecomment-11034767.

@alranel

This comment has been minimized.

Copy link
Member

alranel commented Dec 5, 2012

@simonkuehling, I implemented your idea and it looks very good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.