RE: [CAD_CAM_EDM_DRO] reprap build started

Kevin, Mike,

What's the basic relationship of feeding stock to the travel in X &Y?

Sounds like it would be a direct relationship. So one could calculate a
"feed distance" for the stock, and assign it to another axis to drive the
extruder (scaled, of course)...

Seems like if the X axis needed to move 5" to lay down the filament, then 5"
of stock (or some scale of that) would need to be extruded at the same time.
Just like a "coordinated move"! Has someone already thought of that?

I could see a little program that took normal Gcode, and generated the
"pseudo axis" for the coordinated move.

What's the thinking on this?

Thanks!

Alan KM6VV

> -----Original Message-----
> [mailto:CAD_CAM_EDM_DRO@yahoogroups.com] On Behalf Of Mike Payson
>
> Ah, I see what you are saying. Yes, you are correct that is the way it
> should be done, and that is the way it is done in all modern
> firmwares. 5D is the only one that ever put the acceleration in the
> gcode itself, everything since than does it the proper way.
>
> On Mon, Oct 10, 2011 at 2:03 PM, Kevin Martin <kpmartin@...>
> wrote:
> > By "gcode interpreter/stepper driver" I meant the firmware that converts

the

> GCode moves into realtime motor speed/motion control. This is where the
> acceleration handling should be, no need for custom hardware.
> > In the setup we are using, the acceleration is essentially managed by

the

> skeining software playing with the F words on the G1 commands, with "help"
> from the obtuse implementation of said words by the FiveD GCode

interpreter

> on the mainboard (which treats feed speed as a value to be interpolated

like X

> and Y are, so a move starts at the last move's final feed speed, and
> accelerates/decelerates to the value in the F word of the current move).

As a

> result, one must regenerate the GCode to change axis accelerations.
> >
> > -Kevin Martin