I think the extruder needs to be an "axis" in that it is something that performs coordinated moves along with X, Y, and Z, but I also think there is room for it to be a "non-traditional" axis. By which I mean the gcode value (which represents the amount of plastic to squirt) doesn't need to directly go to drive a motor. There is definitely some room for modeling the very non-linear aspects of the extrusion process and using that model to improve the resulting print quality and perhaps even simplify the gcode.
When you get this written, let me know and I'll be happy to test it out! :) I _think_ you can do a reasonable job of modeling with an accurate temperature and pressure reading from the melt zone. The temp is pretty easy to get, but pressure is another issue... In the mean-time, I'm working on getting my new printer made, and I'll be happy to just get a working servo loop around the extruder motor and the Bowden tube (current plan is to use a laser-mouse optical sensor for feedback on how much plastic got pushed into the hot-end). Question answers inline... On 8/16/2013 8:56 PM, David Bagby wrote: > > I suspect there is not a simple function - there must be more factors at > play here. > So many questions come to mind... > 1) Are the noodles always round or do any extruders do asymmetric or > more complex cross section shapes? They are almost never round. Almost always they are squished ovals. > 2) Is noodle volume rate always a constant? Is it constant per time or > per unit of line integral along the XYZ path or something else? > Is the slicer figuring this out to some reasonable approximation and > taking this out of the equation by the time gcode is generated? > If so, does one configure slicer software to be aware of physical > characteristics of different extruder heads? Not constant. Different speeds and flow rates are used for different parts of the model being printed (external perimeters, internal perimeters, infill, bridges, etc). This is handled by the slicer (CAM) program. > 3) Do some machines mix thin and thick noodles? Can they vary the volume > (thickness) dynamically? What about varying (non-round) cross sections? Yes to all. One example is printing 0.2mm thick perimeter layers for good looking parts, and 0.4mm thick infill every other layer for speed. > 4) I'd bet that start and stop of noodles vs XYZ motion is a function of > the extruder head design and material in use - and probably does not > look like the trapezoidal acceleration graphs used for XYZ. The gcode generated expects a coordinated move between all axis, including the extruder. The acceleration profile is not specified in the gcode. > 5) I've heard that when stopping motion, the noodle has to be sucked > back up a bit to stop dribbling (kids with spaghetti come to mind). > What commands that? Does the slicer figure this stuff out and emit some > "it's impolite to dribble children" gcode after the 3D movement ends? > Would this better better handled in a hal model that knows the > characteristics of the extruder head rather than having that knowledge > in the slicer? > > If forced to use gcode, I could see that happening following the stop of > XYZ motion, but I don't see how one would initiate that "suck back" as > XYZ motion comes to a stop. Maybe "noodle suck" is a function of > deceleration and material elasticity as function of temperature) ? This is called retraction, and it is simply commanded by gcode that moves the extruder axis "backwards". It might be possible to handle this in HAL, but it's not straight-forward. If you simply retract after every move, you're wasting machine time. On the other hand, if you're sitting for more than a brief amount of time, retracting won't completely stop the ooze (it's called ooze, not dribble, in the 3D printer circles) and you'll need to prime the extruder again. Note that retraction is often combined with a move backwards along the recent X Y path in a process typically known as a 'wipe'. This also helps produce clean prints free of ooze and blobs. -- Charles Steinkuehler char...@steinkuehler.net
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
