Re: [CAD_CAM_EDM_DRO] Re: Interface. Gauging interest.

ballendo wrote:

> The fly in the ointment is dealing with things like feedrate
> changes, Estops, and inputs which can arrive at any arbitrary time.
>

The complexity of the handling in this case depends on the nature of the
input. If the input to the device consists of long, complex commands,
as is a potential with the G-Rex, then recalculating for those sorts of
inputs could be a bear.

However, if input to the device is much simpler, short vectors that
execute relatively quickly, then the problem of handling inputs that
interrupt moves is much smaller. More burden is placed onto the PC in
preprocessing the gcode (or whatever) into the required vector moves,
but IMO this is a valid design for a PC-attached device. One of the
design considerations of the G-Rex is for detached operation, so it
needs to be smarter about that sort of thing.

This is what I understood Art to be doing (at least initially) with Mach
for the G-Rex, feeding it fast, short moves so that he could have
maximum control over the movement. This increases the required data
rate, but the rates available with USB mean that this simply isn't a
bottleneck.

The primary problem with this approach is that you can't just feed it
gcode, something has to preprocess the output of your CAM program and
generate the input. If possible I'd like to learn some more about Art's
work with the G-Rex to see what features of the G-Rex he's using and if
it would be possible to develop a lighter-weight device that could
handle only those commands.

Dave K