Support and Dual Extruders

[Chris Chiang]

I am curious: Does anyone else use support material on a daily basis?

However, main question:
Does anyone know the status software support of forming support
material using a second material and second extruder?

Does skeinforge or repG support dual extruder support material? Or is
it something that has to be done through netfabb by printing a support
model and an object model at the same time (if so, how does that work?
I assume it would be similar to printing with two materials).

Thanks in advance,
-Chris

[Far McKon]

> Does anyone know the status software support of forming support
> material using a second material and second extruder?

Skeinforge (as far as I have seen) doesn't have a great support dual
material system built-in. We are talking about doing support by doing
a cool hack.
1) Running skeinforge with support turned on, and setting the support
material temperature below main material temperature
2) in post-processing assigning the 'colder' material to a different
print-head.

That's our plan, but it's not on our feature short-list. Maybe some
other operator has a great idea how to do it.


hack on,
- Far McKon

Desktop Lead and Nerd Herder
MakerBot Industries


P.S. We aim to get our The Replicator branch of ReplicatorG merged
into the main branch, so shortly you should be able to play with new
features!

[rbisping]

dual extruder on skeinforge will work just fine if we correct the E
code bug in the firmware/replicatorg. right now to send distances to a
stepper driven extruder you have to change the E#.# values to A#.# or
B#.#. this is not a problem when working with a single extruder but if
you change tools in the support material script you have to manualy
(at least right now) change the E code or A to a B (assuming T1 is A
and T0 is B).
if the replicatorg driver was able to recognize T0 -> E#.# = B#.# and
T1 -> E#.# = A#.# then dual extrusion with support material would be
trivial. It works with standard reprap firmware but I personaly havent
felt like switching back to marlin. though if it doesnt get corrected
soon i will have to.

[ddurant]

> 1) Running skeinforge with support turned on, and setting the support
> material temperature below main material temperature
> 2) in post-processing assigning the 'colder' material to a different
> print-head.

Skeinforge has supported 'support_start.gcode' and 'support_end.gcode' for a while now - it will insert the contents of those files before & after it writes support commands. It might be easier to put comments in there as commands to the post-processor rather than mess with the temperature. Seems like that'd be less likely to cause problems with people who actually do want different temps for different bits, as skeinforge will want to orbit on temperature changes.

 

It'd also be nice if gcode had 'official' (sic) support for setting tool offsets and stuff. That and replace G1 E (or A/B/etc) with G1 V with the firmware figuring out how to get a certain volume rather than being told 'you need Xmm of filament.' Those two things (plus some gcodes to tell the firmware what size filament you have) would let people finally be able to share high-quality gcode and better enable different machines and extruder styles (like my favorite: the mythical screw-drive that takes pellets instead of filament)

[rbisping]

note: the current skeinforge E values use volumetric rather than
linear rates. so no need to change it to a V value

[Rob Giseburt]

Switch to the makerbot4g (no "a" on the end) driver (in machines.xml)
and you won't have that problem. The "4ga" driver is designed for RPM
control, and hijacks the E axis. (A certain RepG, maybe 27, broke the
makerbot4g driver, but I fixed it and current versions are fine.)

Dave is right, the key is the support_start/end files. I have been
planning on making Dimension handle the support axis more
intelligently as well, and then those wouldn't be necessary, but other
projects took precedence.

-Rob

> --
> You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
> To post to this group, send email to make...@googlegroups.com.
> To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
>

[rbisping]

so with a later repg than 27 (which is the one ive been using) the
driver actualy uses ecodes directly :) great ill be testing this as
soon as i get back to the boat

On Jan 11, 8:36 pm, Rob Giseburt <giseb...@gmail.com> wrote:
> Switch to the makerbot4g (no "a" on the end) driver (in machines.xml)
> and you won't have that problem. The "4ga" driver is designed for RPM
> control, and hijacks the E axis. (A certain RepG, maybe 27, broke the
> makerbot4g driver, but I fixed it and current versions are fine.)
>
> Dave is right, the key is the support_start/end files. I have been
> planning on making Dimension handle the support axis more
> intelligently as well, and then those wouldn't be necessary, but other
> projects took precedence.
>
>   -Rob
>

[ddurant]

> note: the current skeinforge E values use volumetric rather than
> linear rates. so no need to change it to a V value

Not exactly, though that in NO way implies anything bad about the good Mr Giseburt.. :)

 

The current E values tell the firmware the length of filament to draw into the extruder and that (as far as the firmware is concerned) has nothing to do with volume. What I'm saying is that the slicer shouldn't know the filament diameter and the firmware should know it. That way, the slicer would say "this G1 needs 0.16279mm3 of stuff" and the firmware would be responsible for figuring out how to do that.

 

There would also need to be a gcode to tell the firmware what it needs to figure out how to turn that volume demand into extruder commands. For an extruder that takes filament stock, would probably be filament diameter. For something that takes pellets (which are about a bazillion times cheaper than filament) it'd be some other info.

 

The point is to further separate the code that generates the toolpath from the code that implements it. As this separation increases, it gets easier and easier to support different kinds of hardware without having to reslice or tweak/recompile firmware every time anything changes.

[Rob Giseburt]

> > note: the current skeinforge E values use volumetric rather than
> > linear rates. so no need to change it to a V value
> Not exactly, though that in NO way implies anything bad about the good Mr Giseburt.. :)

You had your hand in the volumetric 5d, so you have a say here. ;-)

> The current E values tell the firmware the length of filament to draw into the extruder and that (as far as the firmware is concerned) has nothing to do with volume. What I'm saying is that the slicer shouldn't know the filament diameter and the firmware should know it. That way, the slicer would say "this G1 needs 0.16279mm3 of stuff" and the firmware would be responsible for figuring out how to do that.

That’s on it’s way. The firmware/hardware will be measuring the filament and dynamically adjusting filament speed.

> There would also need to be a gcode to tell the firmware what it needs to figure out how to turn that volume demand into extruder commands. For an extruder that takes filament stock, would probably be filament diameter. For something that takes pellets (which are about a bazillion times cheaper than filament) it'd be some other info.

I’d like to see that pellet thing work out, too!

> The point is to further separate the code that generates the toolpath from the code that implements it. As this separation increases, it gets easier and easier to support different kinds of hardware without having to reslice or tweak/recompile firmware every time anything changes.

I agree completely.

-Rob

[Chris Chiang]

Thanks everyone for the explanations...
and Much thanks to the developers and community, considering how far
skeinforge, repg, and the firmware has come.

I guess this means I'll just sit tight, Considering I'm still running
a TOM mk6+ anyways
But when it's supported, Then I guess I'll splurge on dual extruders!

[ddurant]

> You had your hand in the volumetric 5d, so you have a say here. ;-)

When I'm complaining, it's "you." When I'm praising, it's "we." :)

> That’s on it’s way. The firmware/hardware will be measuring the filament and dynamically adjusting filament speed.

Nice!

 

How are you going to deal with reversal not messing the measurement? Is pushing the same amount you pull always going to come out right? Seems that'd be pretty tricky to get just right.. That and the FW will have to notice that it's happening.

 

Or, now that I think about it more, how's reversal even going to work if you change E to V? Will there just be a gcode for "reverse however much you think is right then push it back on the next extrude command" type deal?

[Rob Giseburt]

On Jan 12, 2012, at 10:58 PM, ddurant <ddur...@gmail.com> wrote:

> Or, now that I think about it more, how's reversal even going to work if you change E to V?

E won't be changed to V, really. There will be a V that sets the
volume expected per mm, and there will be an E that sets how many mm
this movement is. This will be, in this case, the actual mm sqrt(X^2 +
Y^2) of the movement, which serves to both save the firmware that
calculation and to inform the firmware that the toolhead is to extrude
this movement.

Reversal will be in the firmware at that point. ;-)

-Rob

[kunkmiester]

I don't know how printer G-code works, exactly, but generic g-code for
CNC machines does have tool offsets for radius and length. G41 and
G42 will set a tool to a distance away from the path you program in.
Not sure it'd be useful for printing though, since you're computer
generating the G-code anyway--cutter compensation as it's called is
usually used for manual programming.

If the machine is using a generic set of g-codes, that part might
already support this.

[rbisping]

well, Ive been working with repg 29 for about 24hrs now and noticed a
couple of issues with both the E code implimentation and repg its
self. for some reason the driver assumes that A axis is T0 and B axis
is T1 regardless of what the machine profile says. also for some
reason the reset of the E value to 0 by G92 E0 does not reset the
value of the appropriate axis. Ive adjusted my machines mechanical
setup to correct for the first problem and I would assume by not
reseting the E value each layer would probably resolve temporarily the
second problem.

> > instead of filament)- Hide quoted text -
>
> - Show quoted text -

[jet]

On 1/11/12 15:28, Chris Chiang wrote:
> I am curious: Does anyone else use support material on a daily basis?

People with "real" 3d printers, aka professional models. Life without
support material would turn them into big, ugly storage cabinets.

--
J. Eric Townsend, IDSA
design <http://www.allartburns.org>
hacking <http://www.flatline.net>
fabrication <watch this space>

[Keith Schacht]

Eric - what software do people with "real" 3d printers use when
printing with dual extrusion?

[Torsten]

The Dimmension (Stratasys) 1200es series 3D printers use proprietary
CatalystEX software to import and print STL files.

It has limited options to adjust the print; only layer resolution, model
interiors, support fill and scale.

If you want to digg deeper, the Catalyst EX manual
http://www.inventionstudio.gatech.edu/wp-content/uploads/Dimension_1200esUser_Guide.pdf

Torsten.

[jet]

Do any of the pro-systems use free software? Our Stratasys used the
same code and our Epilog cutters used the wonky
laser-cutter-printer-driver, each required a dedicated PC to run the
printing/cutting jobs.

[makerman]

Most professional 3D printers are powder based. Powder based printers
don't need support material.

[Mark Cohen]

I just touched one of my printers. It seems real enough so I'll say repg.

Sent from my iPhone

[Dan Newman]

On 25 Feb 2012 , at 12:24 PM, makerman wrote:

> Most professional 3D printers are powder based. Powder based printers
> don't need support material.

And there's lots of online videos showing their operation. Can be
interesting to watch. Some of the color ones whose parts aren't
very strong but Hollywood loves (my neck of the woods) function
similar to inkjet printers. They just print colored binding glop
as the heads pass back and forth over the powder.

Dan

P.S. The other problem with being near Hollywood is that they just
want consistency in the relative dimensions of the parts they order.
They don't care if a 20 x 20 x 10 mm cube is off by 5% percent. The
engineering firms around here know NOT to order prototypes from the
firms that mostly service the movie industry. Keeping your machines
calibrated takes time and time equals money. I recently went on a
trip with a design engineer buddy who was going to the 3d printing
shop they were using to see why they were getting so many out-of-spec
parts. Shortly after walking in, my buddy said, "Oh oh, I think I
know what the problem is -- look how much animation modelling work
they're printing!" The shop had been marketing to the movie industry
and was doing more and more work in that area and had let go one of
their employees who turned out to be the person who was good about
keeping the machines calibrated.

[sto...@gmail.com]

Define "real". I'm staring at three something. Been bother others regarding their activities on their somethings. Watch lots of videos and follow activities of a lot of others people explorations and building...

real ~ Commercial?