Re: [CAD_CAM_EDM_DRO] Re: Re: G-code user variables; convention?

Ballendo

> we're absorbing the increased processor speed available by
> not prioritising well

yep,I'm with you on that
unfortunatly any extra CPU cycles you free up with a fast interpreter
are NOT going to be used to RUN the code :-(
they ARE going to get sucked up by a big,fancy,ultra bloated GUI
you can count on it
thats why most of the big boys are using dual or even quad CPU
controls -one to do the work and one to keep the operator happy

the user trying to beat a plain old PC
into a machine control is going to have to compromise somewnere
trying throw more Mhz at the problem rarely does the trick

> error checks again at run time

these are a good idea IMO
speed vs. safety = safety wins
but then I've been known to be a bit paranoid when
I'm standing next to a half ton of moving iron :-)


for the compiled gcode
speed had nothing to do with the compiled code on That
machine ,it uses PNC (parallel numeric control) and the code
has to be compiled into tables for each of the sub processors
but that machine is a little out of the scope of this list (~$250k)

Brian