On Aug 16 2013 7:56 PM, David Bagby wrote: > 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.
right. I see now that we were talking about different things. > 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 think the answer is yes. Treat the extruder as a coordinated A and we are much closer to sufficient. > 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? that is complicated. You can get plastic pellets, blocks, powder, and losenge shaped things as well as the noodles. But what comes out is always noodlely out of an "extruder". > 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? this too is complicated. I have heard reports of "no it is not guaranteed to be constant" but that was from a suspect supplier. The issue appeared to be non-constant diameter of the input spool. I have also read something about absorbed moisture, and it would get really wonky if you got one side of a spool wet.... > 3) Do some machines mix thin and thick noodles? Can they vary the > volume > (thickness) dynamically? What about varying (non-round) cross > sections? this can be handled on a multi-head printer. Also think about multi-color and multi-medium printing (so you can print plastic, support, and rubber)... Each one might be slightly different, but in general you only run one print head at a time regardless of how many you have on the machine. So, the motion of each material can be printed independently. > 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. OK, here is where it starts to get fun. you have to pressurize the extruder to get the noodle to squirt out, but if you just stop forcing more filament in then it will ooze out until the extruder pressure drops below some threshold where the viscosity of the melted plastic has trouble exiting the nozzle. So, to combat that, when you want to stop printing, you reverse the extruder a little to at minimum relieve the pressure if not to actually create a little back pressure. But the fun does not end there... The more time you have the filament sitting there and not being squirted out, the more it will volatilize and in essence evaporate. I know someone that had a machine crap out unattended to find the plastic burnt into the print head the next morning. I cannot remember if they ever got that resolved, or just bought a replacement head... > 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) ? It is a function of temperature, pressure, humidity, and material -- but remember that people calibrate their given machine for a given material, temperature, and then adjust it on the fly for humidity..., and they tune it for its overall behaviour. I would have to look at the output of slicer or similar programs, but you need to remember that typically it is implemented in short linear moves instead of more complicated curves, bi-arcs, or NURBS (the later is what I want to play with in the coming months on a new Kossle build). Part of the issue is that there is a repressurization time in the extruder and you have to somehow address that in coordination with the XYZ motion. So, it is better to think about an XYZA coordination. > 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"... I have always thought of it as an rotary reverse with backlash. The "rapid-move" simply happens as part of a backlash compensation. Why I think of this as backlash, is basically the force you have to push to against device to make it 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). I am probably starting to sound like a broken record but you can break it all down to a single motion with a leadin sequence, the motion, and a lead out sequence. However you pressurize and depressureize the extruder is is the same throughout. Figure out something that works and make a function of it. > 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? if you come up with a better analogy I would love to hear it. > 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? all the Stratasys machines I know of are powder-bed machines. They work completely differently. Do they make a filament based machine? > 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. I liked that. I was wondering when pirate bay and the Rap version of O'Riely was going to come out singing... > 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
