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
