On 8/16/2013 2:51 PM, andy pugh wrote: > On 16 August 2013 22:24, David Bagby <d...@calypsoventures.com> wrote: >> I find myself thinking that this conversation is twisted by the >> assumption that an extruder as an axis - I don't think it is. > You are not wrong, but… > The extrusion motor movement needs to be synched to motion. While XY > are not up to speed, the extruder motor needs to run more slowly to > maintain layer thickness. > So, whilst it is not geometrically an axis, it is synched to motion > like a axis.
Ok I get it a bit more now - I was thinking about motion of the extruder head - and not so much about "motion of the noodle that squirts out of the extruder head". Two related but different topics. I can see there is a relationship between "noodle volume laid down" and XYZ motion. Would I be correct to say that coordinated movement with XYZ is a minimally necessary but insufficient condition? 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? 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? 3) Do some machines mix thin and thick noodles? Can they vary the volume (thickness) dynamically? What about varying (non-round) cross sections? 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. 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) ? Much of what has to happen seems inherently not to be an axis motion (as CNC machines define that for the work space); It felt uncomfortable to me to think of clearing a head of noodle material as a "rapid move"... It seems that extruder "action" is a complex function of XYZ motion and .... and .... many other things - more than just the XYZ motion (that the trajectory planner handles). It feels like there must be a better system approach than the "Slicer, gcode, extruder=axis" processing chain that's in use now. As a system this feels "unoptimized". ;-) I'm struck as a 3d printer "outsider" that the slicer layer seems to exist to create gcode; Gcode doesn't seem to be a particularly well suited language to describe the actions that are needed, and the XYZ trajectory planning is (necessary but) insufficient for noodle coordination, and the hardware layer is treating an extruder as "whatever existing thing someone can find that is closest to an extruder".... That feels like maybe it would be interesting to start with "what is an extruder head", what is unique to it, and how would we model one? It would be interesting to know how these things get handled in pro machines. Does any one know what the processing chain looks like for a Stratasys printer? Is gcode even involved inside those machines? Re some other posts in the thread: Charles: The paragraph about the printer Illuminati, Caribbean islands and fox news cracked me up - thanks for the Friday afternoon chuckle. John K: Interesting ideas about spindle synced motion. I'm guessing that it might be a "semi-synced" motion, where the start and end for the extruder action is less coordinated than the middle XYZ motion part (to handle start-up and dribble avoidance). I also get the "if we had enough monkeys" comment - maybe what's happening today is "good enough"... Dave ------------------------------------------------------------------------------ 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
