Why does S3D print the tiniest paths first? Always lifts

[swbluto]

This really frustrates the hell out of me. Why does S3D seem to print the tiniest paths first and the longest ones last, causing the tiny paths to almost immediately lift from the bed thus utterly destroying the first layer? Is there an option I'm not seeing that stops this utterly counterproductive destructive behavior?

[swbluto]

How can I modify the G-code to prioritize the longest paths first? Seems like it should be possible...

I'm a .NET ninja, so if it's possible in theory, I can do it in practice.

I've already created a bot that automates the s3d gcode creation of 1000s models at a time.

[insta]

Slow the first layer down, smash it, or run a 2-layer raft with no fat base layers.

This is likely the result of the "inside-out" setting in the Layers tab. That is a good setting to keep normally, though.

s3d islands.PNG (9.76 KiB) Viewed 11111 times

[swbluto]

Slow the first layer down, smash it, or run a 2-layer raft with no fat base layers.

This is likely the result of the "inside-out" setting in the Layers tab. That is a good setting to keep normally, though.

Yeah, it's set to inside-out. In the past, it seems like "outside in" tended to mess up the outer perimeter. (Didn't look nearly as clean)

It'd be nice to set the "really small" paths to being printed last for the layer, after the perimeters and everything. Should have little affect on the outer perimeters appearance keeping everything else normal. I guess I'll start looking into creating the gcode app.

It'd be nice to set "outside in" just for the bottom layer. Seems like it should be possible... (Just reverse the paths???)

Edit: Just checked the G-code, seems like creating the appropriate app should be easy enough.

[insta]

Make sure you track the change in the E distance and modify it appropriately for each island



edit: dammit now I'm having to write one to prove to myself that I can too.

[swbluto]

Make sure you track the change in the E distance and modify it appropriately for each island



edit: dammit now I'm having to write one to prove to myself that I can too.

Luckily, the E #'s on mine aren't cumulative so it's a pretty easy "copy and paste" paths affair. Just need to conceptualize the "path" structure, and parse the file well.

I'm using the Makerbot Replicator 2x for this. The M2 I use it for other projects (Doesn't have the same problems with "tiny islands" as I don't print "detailed" things on the M2.).

[insta]

Could you email me a problematic gcode? printing [at] pingring.org

I don't care what it is I just want to feed it to an app.

[swbluto]

I looked at the structure of the Gcode file. It's as follows...

-Inner Perimeter (Jumps around a LOT, no obvious order in respect to path distances, probably just "closest first".)
-Outer Perimeters (Doesn't jump, excepts between different outer perimeters.)
-(Any solid fill / infill)
-Gap Fill (Jumps a lot)

Now that I think about it, I'm not really concerned about the order of the second layer... in-out is ideal.

So, I could probably just rearrange the first layer as follows:

Outer perimeters first (same order), then inner (Prioritize by longest paths), then gap fill.

Should solve the issue entirely.

Be nice if I could integrate this directly into S3D. Does it allow me to attach postprocessing apps on the gcode? (Hopefully processed before it creates the X3G files for the makerbot)

[Matt_Sharkey]

I know that Slic3r has the printing order of:

Skirt
Brim
Inside Perimeter
Outside Perimeter
Support?
Infill

How I'm reading your situation is that the infill is being printed first not last? While I know that S3D is SUPER nice, maybe it would be good to have Slic3r on backup for situations like this.

[jimc]

not for nothin but it shouldnt matter how long the line is. if its 1mm or 100, if you have proper bed adhesion then they wont peel up.