Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
mastory

solid & filled in the same object?

Recommended Posts

Is it possible to print an object that is partially filled solid and the rest at some other fill density say 30%? I need to print a pulley where I want the hub to be solid so I can press in a bushing and the rest with a lower density. I should ask, Is it possible using the tools that I currently have available which include Netfabb and as well as Skeinpypy, Skeinforge, RepG...

I suppose it could somehow be modeled that way, but that would not be a very efficient way to use the tools.

If so, how?

Thanks,

Matt

Share this post


Link to post
Share on other sites

You can't do that natively in Netfabb but could possibly if you designed your own style. This would be a big job if it was possible I think. Not sure if the other programs could do it or not. Your best bet would be to redesign the wheel with holes in it or made with spokes where you would like the lower fill.

Share this post


Link to post
Share on other sites

I just had an idea. Tell me what you think. The pulley is designed as a solid, and it already has spokes as part of the design. The spokes are thin anyway, and the rim can be printed at a lower density. I could overlap multiple solids (each decremented in volume) in the space where I want the solid filling. Maybe the slicer might be fooled into creating 'external' surfaces within the volume of the hub. Does what I am saying make sense? Do any of the slicers work on a model that consists of more than one solid?

Share this post


Link to post
Share on other sites
I just had an idea. Tell me what you think. The pulley is designed as a solid, and it already has spokes as part of the design. The spokes are thin anyway, and the rim can be printed at a lower density. I could overlap multiple solids (each decremented in volume) in the space where I want the solid filling. Maybe the slicer might be fooled into creating 'external' surfaces within the volume of the hub. Does what I am saying make sense? Do any of the slicers work on a model that consists of more than one solid?

You *can* print an object with multiple solids inside each other, but it's not exactly straight forward.

I have printed cubes inside of cubes before. The trick is, the outer solid must actually be modelled with walls having an inside and outside facing, so it isn't just a solid cube but a "box" that has walls of a certain thickness. You can then put another solid within the box, and if the sides of the two objects are close enough together, it will print as though the two pieces are continuous. If you have enough concentric objects within one another in this way, the printer *should* just print perimeter after perimeter after perimeter, which pretty much amounts to a solid. It can be a fair amount of work in modelling however to get this set up.

If you have a solid cube with no inside walls, and try to place another solid cube within it, it will not work. The inner solid will represent a hollow spot.

Share this post


Link to post
Share on other sites
This is something I've been thinking about lately. You could slice the model twice, once with 30% infill, and once with 100% infill. Then cut and paste the g-code at whatever layer you want the new infill to start.

I hope in the future there will be a Skeinforge plugin for something like this.

I don't think you could do this because of the 'E' value in GCode. It is always increasing unlike x, y and z which always stay below 210.

Share this post


Link to post
Share on other sites
This is something I've been thinking about lately. You could slice the model twice, once with 30% infill, and once with 100% infill. Then cut and paste the g-code at whatever layer you want the new infill to start.

I hope in the future there will be a Skeinforge plugin for something like this.

I don't think you could do this because of the 'E' value in GCode. It is always increasing unlike x, y and z which always stay below 210.

Admittedly this isn't my area of expertise, but couldn't you manually enter a G92 and set the E value to wherever the new one picks up at?

Share this post


Link to post
Share on other sites
This is something I've been thinking about lately. You could slice the model twice, once with 30% infill, and once with 100% infill. Then cut and paste the g-code at whatever layer you want the new infill to start.

I hope in the future there will be a Skeinforge plugin for something like this.

I don't think you could do this because of the 'E' value in GCode. It is always increasing unlike x, y and z which always stay below 210.

Admittedly this isn't my area of expertise, but couldn't you manually enter a G92 and set the E value to wherever the new one picks up at?

Good point. I did a similar thing yesterday so I should have thought of that.

Share this post


Link to post
Share on other sites
SF Dimension does have an option for relative E value instead of absolute but I've never used it. That (if it works on the firmware) would probably be the thing to do if you wanted to combine different parts of different gcode files.
I wouldn't do that if I where you. The relative E value will cause floating point errors to build up, causing errors in the extrusion amount, and thus creating a less pretty print.

You can do this in 2 steps with Skeinforge (and thus SkeinPyPy Alpha4), if you use the "layers from" and "layers to" options in the "carve" plugin. First slice layer 0 to Y with 100% infill, then slice layer Y to max with 30% infill, and put those 2 gcode files together. You would have to remove the start code of the 2nd GCode file, and reset the E value (G92 E0) at the start of the 2nd GCode file.

You could also print it as two prints, not sure how strong it will be, but I printed this:

IMG_20120211_130234.small.jpeg

In 2 steps, without removing the black platform from the printer. I adjusted the start code to start 7mm higher. (after homing, move up 7mm, reset the Z value with G92 Z0)

Share this post


Link to post
Share on other sites

My intention is to print the pulley lying flat on the bed. I want to print the hub as a solid, being in the center, with the surrounding pulley face hollow or with 30% infill. The solid area is surrounded by the hollow areas, but in the same layers. The approx dimensions of the hub are 5/8"ID, 1-3/4OD, x 1-3/4Ht, The rim is approx 4-1/2"OD, 4ID and 1-3/4HT. Between the hub and the rim are thin webbing or spokes. I would post a picture but no time cause I have to get to work.

First, I will try printing it with everything solid. I am concerned about warping, print time and material usage.

Before I do that though, I want to get a handle on Netfabb which I haven't really made a concerted effort at yet. It seems a bit daunting.

Thanks for your thoughts

Share this post


Link to post
Share on other sites
SF Dimension does have an option for relative E value instead of absolute but I've never used it. That (if it works on the firmware) would probably be the thing to do if you wanted to combine different parts of different gcode files.
I wouldn't do that if I where you. The relative E value will cause floating point errors to build up, causing errors in the extrusion amount, and thus creating a less pretty print.

Not sure I buy that.. With relative extrusion values, each thread basically becomes an atomic operation. You might get a little FP weirdness between what the gcode asks for and what the firmware actually sees but I don't see any reason it's build up over the course of the whole file. Or am I (again) missing something?

Share this post


Link to post
Share on other sites
SF Dimension does have an option for relative E value instead of absolute but I've never used it. That (if it works on the firmware) would probably be the thing to do if you wanted to combine different parts of different gcode files.
I wouldn't do that if I where you. The relative E value will cause floating point errors to build up, causing errors in the extrusion amount, and thus creating a less pretty print.

Not sure I buy that.. With relative extrusion values, each thread basically becomes an atomic operation. You might get a little FP weirdness between what the gcode asks for and what the firmware actually sees but I don't see any reason it's build up over the course of the whole file. Or am I (again) missing something?

In floating point values:

1.5 + 1.5 is not always 3. But sometimes 2.99999999999999999

Also, depending on how the firmware is implemented, it could see "E5.3", and translate that to 74.2 steps (with 14 steps per E unit), and does rounded down, 74 steps. So you could get rounding errors with each move. This doesn't have to be true. But the floating point rounding errors are guaranteed.

Share this post


Link to post
Share on other sites
My intention is to print the pulley lying flat on the bed. I want to print the hub as a solid, being in the center, with the surrounding pulley face hollow or with 30% infill. The solid area is surrounded by the hollow areas, but in the same layers. The approx dimensions of the hub are 5/8"ID, 1-3/4OD, x 1-3/4Ht, The rim is approx 4-1/2"OD, 4ID and 1-3/4HT. Between the hub and the rim are thin webbing or spokes. I would post a picture but no time cause I have to get to work.

First, I will try printing it with everything solid. I am concerned about warping, print time and material usage.

Before I do that though, I want to get a handle on Netfabb which I haven't really made a concerted effort at yet. It seems a bit daunting.

Thanks for your thoughts

I wouldn't worry so much about strength of the inner part which seems to be the main reason you want it solid. If you set extra perimeter layers and about 30% infill, it should be quite strong (as far as plastic goes). As for the warping, it's worse if you print something completely solid. One of the tricks a lot of people use is to print the two parts separately, and leave a hole or two for an M3 screw and assemble the two later. You can also use some glue if that's more convenient, a keyed design would keep the inner and outer from sliding.

I know this isn't a realistic option but it's fun to talk about - it is possible but not practical, if you really REALLY wanted to, you could separate your model into the two parts that you want different infill for. Then after slicing, you could combine the sections of gcode from different files along the layer heights. Of course there is the E value to think about, and besides taking hours of time, there might even be other problems I haven't considered.

Daid, any thoughts on the feasibility of inter-meshing two gcode files with some fancy programming tricks? That is assuming that they were to fit exactly within/beside each other.

Share this post


Link to post
Share on other sites
In floating point values:

1.5 + 1.5 is not always 3. But sometimes 2.99999999999999999

Also, depending on how the firmware is implemented, it could see "E5.3", and translate that to 74.2 steps (with 14 steps per E unit), and does rounded down, 74 steps. So you could get rounding errors with each move. This doesn't have to be true. But the floating point rounding errors are guaranteed.

Yes, but I don't see why the FP weirdness of relative E values is any different than the FP weirdness of absolute E values.

The things you mention apply to both.

edit: and actually, for longer prints, isn't relative E (theoretically) better than absolute since you're almost exclusively sticking to the right of the decimal?

Share this post


Link to post
Share on other sites

I'd say the difference would be that in absolute values the error is only present once, while with relative values a new error is introduced for each operation.

By the way, why is floating point used at all? What's wrong with fixed point math? I think it would be also faster to compute since the MCU does not have native FP support.

Share this post


Link to post
Share on other sites
I'd say the difference would be that in absolute values the error is only present once, while with relative values a new error is introduced for each operation.

Why? On one method, the firmware resets E to 0 on each thread. On the other, it uses whatever the previous E value. It's the same extrusion length either way.

 

By the way, why is floating point used at all? What's wrong with fixed point math? I think it would be also faster to compute since the MCU does not have native FP support.

Another in the "because it's always been that way" list, I suspect.. :(

Share this post


Link to post
Share on other sites
By the way, why is floating point used at all? What's wrong with fixed point math? I think it would be also faster to compute since the MCU does not have native FP support.

Another in the "because it's always been that way" list, I suspect.. :(

Because... it works, is my guess. The code is complex enough without fixed point math. In general, floating point is good enough for what we do.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!