On Tue, Dec 7, 2010 at 3:19 PM, Chris Radek <[email protected]> wrote:
> On Wed, Nov 24, 2010 at 01:15:47PM -0600, Stuart Stevenson wrote: > > Gentlemen, > > What would be the difficulty level and/or objections to reading the > tool > > table on 'CYCLE START' rather than a separate 'reload tool table' > operation? > > My ultimate preference would have the tool table read continuously so > > changes would be available on the next line read from the program. > > We just scrapped a multi-thousand dollar part because the operator > forgot > > to invoke the 'reload tool table' operation. > > I looked into this briefly - it isn't as easy as I had hoped. I > wanted to reload the tool table (into the canon level) at every resync > (whenever the interpreter asks canon for the current machine state). > The interpreter already reloads the tool table from canon at sync. > > Frankly I am not sure what this would break. > > I am nervous about encouraging people to edit the tool table manually, > because especially on a random tool change machine, EMC modifies and > rewrites it all the time. If you have a stale copy in an editor and > you overwrite an updated one, you can cause yourself spectacular > problems because EMC would lose track of pockets vs tools. > > Do you know in more detail what happened? Why did the operator > manually edit the tool table? What did he change? On my touchy-based > system I use only tool touch off, and I set tool diameters with G10 L1 > Pn R... This is foolproof, even for me. (Besides, it doesn't have > a keyboard...) > As far as I can tell (the shop owner does not get the whole story until WAY later): on the cinci w/axis interface the operator and programmer agreed to raise the program .075 to leave a little extra material for the first part/first time through the program the operator added .075 to the tool length and reloaded the tool table and ran the part - so far so good from this point on confusion reigns the operator and programmer talked about how to lower the program and agreed to lower the program the specifics on how this was accomplished are now points of question the end of the part was undercut by .150 the operator reloaded the tool table the tool began cutting the part correct all are in agreement that the reloading of the tool table fixed the tool misposition I have tried to determine what could have happened. .075 and .150 are realistic error results from .075 offset changes although arriving at -.150 from a beginning move of +.075 leads me to believe there must have been quite a discussion on how to get there all are also in agreement as to not knowing how they arrived at the -.150 position - it sounds as if they were one step away from being correct my first post on this thread was immediately following the error and correction - more information to muddy the water has since bubbled up the operator has checked the tool positioning with a 1/2/3 block after every tool change since the miscut part today he told me the tools have repeated within .001 since - he is finally beginning to trust the machine the whole story will eventually surface - when the hurt/fear of a scrapped part has softened - people will talk about how to avoid problems and let it slip as to how this occurred - I have seen this happen many times thanks for looking Stuart -- dos centavos ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
