On Wed, 2012-03-21 at 19:24 +1100, Erik Christiansen wrote: > On 20.03.12 22:21, Kirk Wallace wrote: > > I've got my brain sore thinking about this, so I'm a little foggy, but > > it seems the safest way to do this is to break the g-code program into a > > separate program for each tool change. > > If doing that, then we might keep the files for a job in a directory > named according to the job. > > > If there [were]
"where" might have been a left over accent from Saint Patrick's Day. > a way to make this look like one run, that would be > > better. > > It is easy to have a filter program process a "#nextfile somefile" last > command in an input file, to achieve file sequencing. However, it is > just as easy to keep the entire part program in a single file, and > synthesise "separate files" of gcode on the output of the filter. > > Do you visualise an M2 separating the tool runs, on the output of the > filter? Whatever is needed to make a full file that could stand on its own if needed. > How much jogging do we really want to do, though? Isn't it a bit more > convenient to program rapids to a fixed probing station, where we also > do the toolchanges? (Or toolchange nearby, to avoid dropping things on > the probing sensor.) Perhaps I haven't understood all the variables in > your following paragraph?: 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. > > Also, it would be nice to be able to use the same original part file > > for machines with repeatable tool holders or machines or tool holders > > that need a touch off for each change. 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. > If touch off isn't needed, then we just go to the toolchange position, > omitting the touch off position? Yes, I think so. > A machine-specific "toolchange" > subroutine could conveniently wrap up all of that customisation, > couldn't it? (And with "#include" functionality in the filter program, > such a subroutine could be in a file of its own, or several could be > included in the one file, if they are always used together.) > > > The key to which type of change would be needed could be a setting in > > a configuration file or a special code in the tool table. > > Rather than spreading this stuff all over the system, would it be more > convenient to just let the "toolchange" subroutine do the customisation in > the part program? 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. 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. > > 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. > > If it's all one file, then what sort of checks do we need to perform? > Even if it is something that gcode can't intrinsically do, such as > reading back the current state of a modality, the translator can do that > with its input. (It's doing that now on distance mode, so that a > "G81 ... L3" can be given a fleeting G91, with automatic restoration to > G90 before proceeding to the next line, _if_ that is the setting current > in that section of the program.) The above is new to me, but 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. > > Basically, automating what an operator would currently need to do by > > hand. > > And that is what we're all here for. ;-) > > If we need to tell the filter something about what we've done during the > toolchange, then that could be written to a temporary file or named > pipe, for the filter to inspect before proceeding with the next code > segment. That also would not necessitate splitting the part program into > subfiles, because switching a filter's input stream between input files > is trivial. An "Await Signal" command is easily added to the > translator/filter currently in the works. It could alternatively respond > to a unix signal, or check a semaphore, or whatever we find most > convenient. > > Your ideas look like a lot of fun to implement. To make it more > seamless, it ought to be manageable to make the filter respond to unix > signals (thus obviating the need for a communications file, just to give > a resumption "go ahead"), and it may be possible to add an AXIS button > to send such a signal. > > 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. > > Erik I think having a good outline of the manual procedure on the wiki could be a guide to what could be done. 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. 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. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA ------------------------------------------------------------------------------ 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
