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 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?
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.
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.
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?
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.
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.
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.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.
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:
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)
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
As long as those spokes aren't in mid air you should go alright. You might get slight warping but only on the bottom. It will be fine at the hole and top so overall it should be a good wheel. Good luck. Feel free to show us the result.
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.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.
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?
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.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.
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.
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.
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?
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.
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.. :(
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.
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
owen 19
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.
Link to post
Share on other sites