O numbers i think were originally intended to indicate different Operations on a part. O1 would be drill a hole for instance, and then O2 would be to drill another hole, after having rearranged the part in the machine tool to the appropriate orientation, say by rotating it 180 degrees around the B axis.
to that end, program registry in the machine tool memory is delimited by O number signifying the beginning of an operation, and M30 or M2 delimiting the end of a part operation, depending on whether the tape is to be rewound for another cycle of the same operation on a new part. in practice, an operation on a part (i.e., one chunk of material clamped up in a machine tool) commonly includes the action of multiple different cutting tools to complete the operation. with automated tool changers and tool length offsets for the various tool socket/cutter combinations, the routine of switching between different tools is not complex. at each cutter change, the machine tool moves to a 'safe' location, mechanically updates the physical cutter and associated geometric nc parameters, and the operation continues. (tool probing in this case could account for cutter wear, breakage, or misalignment from contamination of the tool holder interface with the machine tool by swarf.) in the case that tool changing is done by a squishy automaton, these assumptions usually apply: the tool is changed to the correct tool (machine requests correct tool), and the tool is identical in all specifics to its last instance of use (i.e. offsets and geometry are unchanged). in this case, tool change is not complex, and routine implimentation during a part operation is straight forward. accuracy depends upon, as with automated tool change, the machine tool/cutter socketing interface, and probing can possibly improve this. in the case that automated tool changeing is prone to frequent and unpredictable failure, and squishy automatons are also prone to frequent and unpredictable failure, and previously envisaged half brained attempts to implement tool probing features are eventual failures due to swarf/coolant factors, and given that a spindle motor may just go tits up on a random day, or that every fucking rolling ball in the whole place is at its crumbling end, routine implimentation of the tool change operation is trivial, and will be completed prior to already expired deadlines at a loss. machining is the best. --- On Thu, 3/22/12, Erik Christiansen <dva...@internode.on.net> wrote: > From: Erik Christiansen <dva...@internode.on.net> > Subject: Re: [Emc-users] Tool change question > To: emc-users@lists.sourceforge.net > Date: Thursday, March 22, 2012, 2:09 AM > On 21.03.12 10:27, Kirk Wallace > wrote: > > On Wed, 2012-03-21 at 19:24 +1100, Erik Christiansen > wrote: > > > On 20.03.12 22:21, Kirk Wallace wrote: > > > > If there [were] > > > > "where" might have been a left over accent from Saint > Patrick's Day. > > Please accept my apologies for the pedantry. (One possible > compensation > is that a little bit of obsessive-compulsive focus is good > for making > progress on a software project.) > > > Since, at touch off tool change periods, we are between > separate part > > files, the operator can do whatever is normally done to > set up a job, > > such as jog to the workpiece, pull out a favorite dowel > pin and finely > > jog for a proper slip fit between the bit and > workpiece, enter in the > > proper offset, repeat for each axis and finish with > clicking "Resume" > > but actually starting a new run. > > OK, so good so far. But where a filter is providing the > preprocessing > you've described, and other features mentioned on this > thread, it will > also be paused during the toolchange, and so also needs to > resume. > > To avoid the need for clicking two "Resume" buttons, can we > make a small > tweak (in HAL?) to either send a unix signal, or write a few > characters > to a unix named pipe, to tell the filter that the coffee > break is over? > (I haven't looked at that side of things yet. Dancing with > lex and bison > half the night is fun enough at the moment.) > > > I think it would be better to have the g-code remain > portable between > > different machines and have the tool change variations > handled in the > > local application rather than having a different g-code > file for each > > machine even though the part is the same. In the real > world, it seems > > that there is always something about a machine that > requires a change > > in the g-code, but I'd like to avoid it if we can. > > The translator supports "#include". That allows us to write > one portable > part program, which includes one or more customisation > files, just like > the header files which allow one linux kernel to be used on > many distros. > > The customisations might be such things as one machine > having a combined > toolchange & probing station, while another has them > separated. It seems > more useful to have all of that collected in the > part-programming > domain, rather than some of it hived off elsewhere, in areas > possibly > unfamiliar to those who may have to tweak the set-up, when > the probing > station breaks, and a different one is installed. But that's > just > opinion. :-) > > > The more I think about this, the preprocessor could > check the g-code for > > all of the tools called, then check to see if any tool > parameters are > > missing for those tool entries and flag the tools with > missing > > information for special handling. > > It does seem ever so slightly peculiar to put incomplete > information > into the tool table, without checking that it is valid, and > then apply > checking during a machining job, as an afterthought. ;-) > > The input program might be in 50 or a hundred files if we > put each > subroutine into its own file (in a step toward solving > Gene's > "invisibility" concerns), so it would probably be more > convenient to > just check all tools in the tooltable, as part of a > "pre-flight check" > before starting to make swarf. That would avoid the need for > making an > additional pass over all those files, just to avoid checking > the tool > table properly. If complete checking encouraged the use of > tooltables > containing only usable tool parameters, then it would be no > bad thing. > > > The tool table has totally changed (for the better, at > first glance) > > since the last time I looked at it, so I'll need to get > up to speed on > > tool tables. > > Those of us with only collets for toolholding might not use > a tooltable, > instead probing and using a "G10 L1". If validity criteria > can be > formulated for the tooltable entries, then they should also > be applied > to such in-line tool specifications, I figure. > > > > > A preprocessor could scan the g-code file for > tool changes and > > > > create sub files of the commands between > tools of the touch off > > > > variety. Then call the subfiles in sequence > with a touch off macro > > > > between sub-runs. > > > > > > Ah, that sounds very much like the understanding > of your idea that > > > I'm ploughing through, above. > > > > > > If you're happy to use a more human-readable > dialect of LinuxCNC > > > gcode, then we can add a toolchange command, > conforming to your > > > specifications, and syntax which we find most > readable, to > > > infrastructure which is already coming together. > > > > > > > Checks would be needed to make sure the > contexts don't change or > > > > are correct. > > I'm not sure what we're checking against, here. The machine > state is the > machine state, and that is whatever it is. It is my > (limited) > understanding that LinuxCNC cannot intrinsically test the > current state > of its many modalities, so we don't seem to have anything > that can be > checked, AIUI. > > The translator treats modalities in a non-presumptive > manner. i.e. It > allows for the possible states, where it cares what they may > be. So long > as LinuxCNC is paused in a resumable manner, then its > machine state > picks up where it left off. I'm not sure why that isn't > enough? > > Do we need more than just reasserting any needed modalities > at the start > of each file, as is recommended in the LinuxCNC doco, IIRC. > Disasters > due to typos in the initialisation in one file can then be > avoided by > using #include to prefix a common set of modality states to > every file. > > > my concern is to start the new run (subfile) with the > proper header, > > with the new header derived from the context that the > previous subfile > > ended with. Sort of like saving and restoring the stack > and other > > registers to handle an interrupt. > > But LinuxCNC doesn't know its current state in an exportable > way, so has > nothing to put on a stack, AIUI. And we don't have gcode > interrupts. For > the moment, we seem to only have the recommended good > practice of > starting each file with explicit modality settings. > > Each file can then explicitly reassert anything non-standard > that it > needs. It might be good practice to only break programs > between > self-contained processes. If that is done, then including a > common file > may be a workable solution. > > Is there then anything which still needs checking, and if we > have to > specify a reference for checking against, then isn't it just > simpler to > assert those modal states? (If there's something I'm not > grokking, > please give me a shove in the right direction.) > > > > If we can clarify exactly what is required, then > I'd enjoy adding to > > > the translator the parts it can do. (i.e. pretty > much all of it, > > > barring a button or two in AXIS, AIUI.) > > > > > > Even if we start with something basic, it can be > tweaked as we go > > > along. > ... > > > I think having a good outline of the manual procedure > on the wiki > > could be a guide to what could be done. > > That sounds pretty good to me. > > > I think Dave's comment about being able to queue and > run g-code files > > would be part of the solution and could be a feature > that could stand > > on its on merit. > > Well it already exists, if you're amenable to using more > words and less > "M50 P1" or "G33.1 K 0.05". I'll add a "#nextfile" command > to extend the > second method of file chaining without limit. > > There's 6 pages of elementary doco so far, a couple of test > files to > further demonstrate syntax, and an executable which runs > fine on ubuntu > and debian. There are still some gcodes to be done, but most > of the basic > ones are there. Subroutines and looping are next on the > list, but > If-Else-Endif are implemented and tested. It's just rather > "alpha", > given that not everything is there yet. > > > Gene's concern over subroutines makes it more > "interesting". I'm not a > > big fan of subroutines, but they aren't going away, so > they need to be > > addressed. The Tormach manual (good reading) > > http://www.tormach.com/uploads/398/PCNC1100-3-3-UM-C1-2-1-pdf.html > > > > > has some insights on using subroutines and tool radius > compensation > > and suggests not using them or using them with > restrictions. The > > preprocessor could look for and react to these issues, > such as fault > > out if it sees a subroutine that spans a tool change, > maybe. > > I'll read that, once I've done tonight's stint on > subroutine > translation. (It needs a symbol table if I'm to replace > those 'orrible > 0-numbers with proper function names. So it won't be done in > one > evening.) > > If we follow that advice, and use no LinuxCNC subroutines, > we could > instead use #include to the same end, just by placing call > parameters in > #1 to #30, and then using "#include > ../routines/hexagonal_pocket.hr" to > invoke the chunk of code that is our subroutine-in-a-file. > > Since no o-guff is used, there is then none of the > invisibility which > troubles Gene, AFAICT. > > I'm not saying that we won't have to whack a molehill or two > with a > shovel, to get this thing onto the tarmac, but I don't see > anything > which needs the old Cat D6 from out on the farm. > > Erik > > -- > A language that doesn't have everything is actually easier > to program > in than some that do. > > > > -Dennis Ritchie > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
