>
> I think the masking should continue to be honored. I think masking
> the overrides is VERY rarely used (I know I've never programmed it
> by hand), but where it is used it is critical.
>
> The G76 threading cycle uses this functionality for instance - when
> it gets to the end of the thread pass, it needs to rapid out. I
> would not want to break that. If you're proofing a lathe program
> with rapids turned down, you'd want the little thread exit move to
> still rapid out, but the rest of the positioning moves to be slowed.
> That is the functionality you should currently get.
>
My thought was that masking rapid override by M code should not be
Honoured.
Waiting for a cycle to finish would make sense, just as we do for
feed override during synched moves. The rapid out move should be
considered part of the thread cutting.
My though is that you shouldn't need the M code on so you don't
crash the thread using rapid override.
The same problem comes around if you set the M code on for the
threading then forget to turn it off after. (as it is coded now)
If you prove the program with rapid override, after the thread it won't
be honoured, possibly allowing a crash.
On the lathe I used, rapid and feed setting were overridden by the
same rotary switch, but only when in 'single block mode'
The rapid out move was still a synched move so rapid override
didn't have effect IIRC.
Cheers Chris M
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
