Now, I would love a slicing program that was able to provide cleaner seams

Now, I would love a slicing program that was able to provide cleaner seams on prints. But it doesn’t look likely, thanks to the heavy-handed patent application behaviour of Stratasys. Really makes you appreciate open-source, doesn’t it?

You did try the continuous Z option (the Joris option) in Cura? Solves this problem in a better way IMHO.

@Jan_Wildeboer is right, but it eliminates the problem not completely. There are some seams left…

You gotta admit that it’s a pretty clever solution, though…

so what happens if someone copies this and sticks the source of say… a build for slic3r on pirate bay?

@Jonathan_se5a_Sorens thats the problem of patent requests. You have to make your idea public, before it get’s secured.

Uh, slic3r already does this. It was in the commit mentioning a 45 degree turn in when finishing the infill. Has done it since somewhere around 0.9.3 I think.

ah right. no problem then.

Well, I’m trying to find the commit, so we can invalidate their patent.

Found it!:

And the second implementation, after it was found the first one was poorly implemented:

Since this patent hasn’t been granted yet, how do we make sure the reviewer sees these commits as prior art?

well to be honest it borders on the whole ‘non obvious solution’ requirement as well.

For all the fact that there is no way for me substantiate this statement, the same approach had occurred to me when I was considering how to overcome those annoying seams. At the time, it seemed (hah) such an obvious solution, I just assumed it was not feasible for some reason. Apparently not.

The patent application was filed 2012-12-07. Which puts the priority date to 2011-12-07. So you have to show this method was used before the priority date. The commit is 7 months old, so it doesn’t count.

It’s conceptually similar to subtractive manufacturing (milling) using lead-in and lead-out when making pocket cuts… But different enough that I suspect they can argue its non-obvious.

Could skeinforge’s “Fill - Thread Sequence Choice” qualify as prior art? I always do Loops->Infill->Perimeter so that my perimeters are well reinforced, a side-effect of which is that the final Perimeter loop always starts from the inside, where the loops & infill finish. It’s been an option for several years.

The patent’s independent claim 1 states: “an interior region of the layer defined by the perimeter, wherein at least one of the start point and the stop point is located within the interior region of the layer.” (highlighting mine)

When printing a single object volume (single outward-facing surface; no internal voids or holes), both your starting points and ending points will always be internal:

layer 1: (interior) loop->infill->perimeter
(move up Z & to inner point for start of next layer)
layer 2: (interior) loop->infill->perimeter

You will always get something that “looks like” Fig. 7 (adjacent meeting point) or Fig. 10 (crossing meeting point).

When you change the loop order to perimeter->loop->infill or perimeter->infill->loop you’ll get structures like Fig. 15, 16.

Fig. 14 would happen automatically with some variation of loops->perimeter or perimeter->loops with infill set to 0%.

At the very least, they need to tighten up their language to only encompass the intentional novelty of Fig. 5, 6, 8, 9, 13.

Before even looking for prior art I was thinking that this is probably not novel, I would say it’s obvious.

" If a patent application is an original, non-provisional patent application, not a continuation application, and not previously filed in another country, its filing date is usually the same as its priority date."

In that case, the slicer commit would most likely invalidate this patent.
Someone get the EFF on the line. :slight_smile: