[Proposal] Layer change inside part

[pieniacy]

Is it possible to add "Infill" among "Seam position" options? I did a little search on this and it seems there is no slicer implementing such thing, is it for some reason difficult to do?

[lordofhyphens]

1) You're not guaranteed to have infill. 2) Perimeters are normally printed before infill, which IIRC is the cause of the "seam", which is a relatively slow Z move up to the next layer from the previous layer.

"Nothing unreal exists." - Kiri-kin-tha's First Law of Metaphysics.

On Thu, Apr 7, 2016 at 11:31 AM, pieniacy notifications@github.com wrote:

Is it possible to add "Infill" among "Seam position" options? I did a little search on this and it seems there is no slicer implementing such thing, is it for some reason difficult to do?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/3299

[pieniacy]

1) ok, but most of the time we print with infill - hollow or very small parts happen rarely 2) when i imagine best seam-hiding path i see something like:

• starting layer inside print at calculated seam point
• printing part of infill
• printing perimeters
• finishing infill and ending roughly where seam point is
• going up at that point

[mrvn]

I thought seam was where each perimeter starts and stops. Nothing to do with when it moves one layer up.

If its actually only where the Z change happens then that setting seems rather pointless. Half the printers will have lift so moving the head anywhere will change Z anyway, a lot more than one layer. From the other half 99% you have infill and the Z move up would be over infill and again the setting would be pointless. And for the rest it would far more sense to move away from the outer perimeter for the Z move if that is what you call seam.

[pieniacy]

Ok, i get your point. Thanks :)

I have an idea of continuously printed perimeter, but i will work on it a bit and see how it works. On 11 Apr 2016 11:33, "Goswin von Brederlow" notifications@github.com wrote:

I thought seam was where each perimeter starts and stops. Nothing to do with when it moves one layer up.

If its actually only where the Z change happens then that setting seems rather pointless. Half the printers will have lift so moving the head anywhere will change Z anyway, a lot more than one layer. From the other half 99% you have infill and the Z move up would be over infill and again the setting would be pointless. And for the rest it would far more sense to move away from the outer perimeter for the Z move if that is what you call seam.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-208252101

[lordofhyphens]

That is vase mode :) On Apr 11, 2016 11:49 AM, "pieniacy" notifications@github.com wrote:

Ok, i get your point. Thanks :)

I have an idea of continuously printed perimeter, but i will work on it a bit and see how it works. On 11 Apr 2016 11:33, "Goswin von Brederlow" notifications@github.com wrote:

I thought seam was where each perimeter starts and stops. Nothing to do with when it moves one layer up.

If its actually only where the Z change happens then that setting seems rather pointless. Half the printers will have lift so moving the head anywhere will change Z anyway, a lot more than one layer. From the other half 99% you have infill and the Z move up would be over infill and again the setting would be pointless. And for the rest it would far more sense to move away from the outer perimeter for the Z move if that is what you call seam.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-208252101

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-208445128

[pieniacy]

no, no, not vase, i mean normal layer by layer printing, but setting paths so that while being on perimeter no stops are made On 11 Apr 2016 21:39, "Joseph Lenox" notifications@github.com wrote:

That is vase mode :) On Apr 11, 2016 11:49 AM, "pieniacy" notifications@github.com wrote:

Ok, i get your point. Thanks :)

I have an idea of continuously printed perimeter, but i will work on it a bit and see how it works. On 11 Apr 2016 11:33, "Goswin von Brederlow" notifications@github.com wrote:

I thought seam was where each perimeter starts and stops. Nothing to do with when it moves one layer up.

If its actually only where the Z change happens then that setting seems rather pointless. Half the printers will have lift so moving the head anywhere will change Z anyway, a lot more than one layer. From the other half 99% you have infill and the Z move up would be over infill and again the setting would be pointless. And for the rest it would far more sense to move away from the outer perimeter for the Z move if that is what you call seam.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-208252101

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-208445128

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-208520961

[lordofhyphens]

Generally each perimeter is printed completely on its own if possible, as a loop, so I'm not quite sure what you are asking for now. :(

[Drmaestro]

I think what he meant was creating a continous loop which includes the perimeters and the infills. If there is a certain amount of overlap between the infill and perimeter, the printing head can transition from the infill to the perimeter without any interruption. It can start at the infill, and then go to the perimeter and come back to the infill again for beginning of the next layer. I think Cura does something similar if set at the options (infill before perimeters) and this could be helpful for external layer quality. It is true that not all of prints have infills, but it could be an option for prints which have an infill. This might be more complicated than it sounds however, as it might require changing the slicing logic.

[lordofhyphens]

@Drmaestro You can already tell Slic3r to print infill before perimeters (and external perimeters before internal perimeters).

"Nothing unreal exists." - Kiri-kin-tha's First Law of Metaphysics.

On Tue, May 3, 2016 at 4:18 AM, Drmaestro notifications@github.com wrote:

I think what he meant was creating a continous loop which includes the perimeters and the infills. If there is a certain amount of overlap between the infill and perimeter, the printing head can transition from the infill to the perimeter without any interruption. It can start at the infill, and then go to the perimeter and come back to the infill again for beginning of the next layer. I think Cura does something similar if set at the options (infill before perimeters) and this could be helpful for external layer quality. It is true that not all of prints have infills, but it could be an option for prints which have an infill. This might be more complicated than it sounds however, as it might require changing the slicing logic.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-216475977

[thinkyhead]

As an alternative, even (or especially) when printing perimeters, the last few mm of one layer should do a "smooth transition" to the next layer instead of stopping XY and moving Z straight up. This would be essentially the same as the "Joris" or "vase" style of printing, but just for the transitions. The slicer could account for the ramping up to the next layer with a gradually-increasing E flow, and a corresponding ramping-down of E flow when finishing that first perimeter.

This could potentially eliminate the "Z scar" altogether, by eliminating the stop where the extruder can ooze, and smearing out the material over more distance.

[pieniacy]

@Drmaestro exactly! sorry, maybe i couldnt express it properly @thinkyhead i like your idea as much as mine, it also should solve the problem, but i imagine it would be much much more difficult to implement

[thinkyhead]

To me, implementing a slicer seems like magical voodoo. So I bet @alexrj would have a lot of "fun" figuring it out.

[mrvn]

Slic3r generates closed loops for the perimeters. But then it has to break open that loop to actually print it. Where it breaks it the head will move from one perimeter to the next or from perimeter to infill or to the next layer. Doesn't really matter where it goes, point is that it breaks the loop often leaving a scar.

It might be beneficial for slic3r to never (unless impossible to avoid) lift/retract at the end of the outer perimeter. Instead the head should move inwards and then lift/retract That way any scar caused by the lift/retract would be inside where it isn't seen.

Similar with un-lift and un-retract. Don't do that on an outer perimeter. Do that somewhat inside and then start the perimeter loop by printing towards the outside edge. A single perimeter would then look like this: ... | X |...

[gege2b]

Hi Good idea, but I read another suggestion similar to this one a few years ago, and if my memory is good, @alexrj said that this way of handling perimeters start/stop is patented

https://github.com/alexrj/Slic3r/issues/1037#issuecomment-18401135

anyway I don't know how that evolved since 2013

[lordofhyphens]

http://www.fabbaloo.com/blog/2013/5/14/stratasys-solves-those-troublesome-3d-print-seams.html

http://www.google.com/patents/US20130095303

AFAIK it's patented, so it can't go into Slic3r.

[lordofhyphens]

Closing this issue. Feel free to reopen if you find that the patent gets invalidated.

[a4jp-com]

A z-lift with wipe pretty much gets rid of seams so you wouldn't need the internal bump that is shown in the patent.

[mrvn]

Also the patent is for additive methods. I want this for my CNC mill for subtractive construction. :) Those seems on the inside of holes are ugly.

[Patola]

@lordofhyphens prusa slic3r just implemented "rear" as an option to seam position, which is exactly what seam hiding / the stratasys patent deals with. Should it be backported to slic3r or will it be forever absent?

KISSlicer also implements it as "destring". @bubnikv @alexrj

[bubnikv]

prusa slic3r just implemented "rear" as an option to seam position, which is exactly what seam hiding / the stratasys patent deals with. Should it be backported to slic3r or will it be forever absent?

The "rear" seam is something else. It means, that Slic3r will position the seam close to max Y while still avoiding overhangs and trying to put the seam in the corners.

On Mon, Feb 20, 2017 at 12:39 PM, Patola notifications@github.com wrote:

@lordofhyphens https://github.com/lordofhyphens prusa slic3r just implemented "rear" as an option to seam position, which is exactly what seam hiding / the stratasys patent deals with. Should it be backported to slic3r or will it be forever absent? [image: selection_702] https://cloud.githubusercontent.com/assets/2991620/23123661/05baf982-f748-11e6-9123-e66905571256.png

KISSlicer also implements it as "destring". @bubnikv https://github.com/bubnikv @alexrj https://github.com/alexrj [image: kisslicer v1 5 release linux64 unregistered _693] https://cloud.githubusercontent.com/assets/2991620/23123637/fb7b756e-f747-11e6-9cc3-b506e48bada7.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-281057594, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I9cNuLpfKJ7zBfxy9H2aUAzDjCrQks5reXtdgaJpZM4ICPcz .

[Patola]

@bubnikv thanks for the clarification and sorry for the confusion.

[lordofhyphens]

Depends on how involved @bubnikv made the implementation ;)

I can definitely see a use for some better control of seams, although the described behavior sounds like it might have some surprises lurking (this sounds mostly like aligned, except biased towards max Y).

[bubnikv]

I can definitely see a use for some better control of seams, although the described behavior sounds like it might have some surprises lurking (this sounds mostly like aligned, except biased towards max Y).

Yes, it is exactly that, aligned towards the max Y. The issue with the implementation is, it calculates a linear weighted sum of various cost functions, therefore it may not do what you would like it to do. This is a perfect task for a neural network to learn the intents. Some volunteer to take the challenge? :-)

On Mon, Feb 20, 2017 at 2:44 PM, Joseph Lenox notifications@github.com wrote:

Depends on how involved @bubnikv made the implementation ;)

I can definitely see a use for some better control of seams, although the described behavior sounds like it might have some surprises lurking (this sounds mostly like aligned, except biased towards max Y).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3299#issuecomment-281082696, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I_juJxfCsPOxGdyThrnFtTXaXb5Aks5reZjKgaJpZM4ICPcz .

[lordofhyphens]

Yeah, I could think of a few corner cases where it would surprising. Probably still worth including :), assuming I can port it over.