> Message: 3
> Date: Wed, 16 Feb 2011 15:15:22 -0600
> From: Chris Radek <[email protected]>
> Subject: Re: [Emc-developers] G73 retract
> To: EMC developers <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Feb 16, 2011 at 10:44:57PM +0200, andy pugh wrote:
> >
> > Having it hard-coded still feels wrong, but I don't have a better
> solution.
>
>
> This user showed up on #emc (damik1) and we talked about it. He may be
> working on a better solution, which is to have this value configurable
> with an ini file entry. The default, if it is unspecified, would be to
> use the current value.
>
> I think extremely few people would ever need to change this value.
> This is the first time I've seen someone ask about it.
>
> Chris
>
>
>
> I have a two cent contribution to this thought.
Many times over the years I have seen the 'need' for this capability except:
1: if you have a few parts to do, by the time you figure out the most
efficient step distances for each step you realize if you had just pecked
the parts with the regular, simple stepping command the parts would have
been done sooner.
2: if you have enough parts to warrant the effort to determine the correct
step amounts for each step you realize that if you have 3 step amounts
available you really need 4 or 5 step amounts and your efforts will be
better served by a macro and a simulated step cycle in g code. In other
words, write the cycle in g code, put it in a macro and call it for every
hole.
3: if your production 'need' requires this effort you should purchase a
coolant fed drill and realize a lot of time savings.
the law of diminishing returns is encountered rapidly in this process
thanks for allowing my dos centavos
Stuart
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
