On Wednesday, March 21, 2012 10:35:09 AM Erik Christiansen did opine: > 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. > Humm, not something that can be done currently as an oword named file must be in the NC_FILES defined path. HOWEVER, I didn't try to use the oeagle/tedautoz call format when I was doing the pcb's. I assumed that it would not work but would be happy to learn there is a way.
> > If there [were] 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? > > 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 This was the problem I encountered. I at first made a probing location, a pillar with the probe surface on top of it that stood alongside the pcb pallet, but after breaking several bits and crushing the probe surface 2 times because I forgot to move and reconnect the probing clip, I gave up and now probe the corner of the pcb itself, removing all those variables from the equation. I do it slow enough there is no mark left on the pcb. > your following paragraph?: > > 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. > > If touch off isn't needed, then we just go to the toolchange position, > omitting the touch off position? 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? This was my final solution, with any xy compensations being done in the G55 world for the top of the board, and the G56 world for the bottom of the board. z offsets from the probing were applied in real time after canceling any that existed prior to the probe. That stuff can build up and eat your lunch. > > 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.) > > > 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.) Is that not (at this time) a function a 'custom.hal' can do? > Even if we start with something basic, it can be tweaked as we go along. > > Erik This is beginning to fit my own wishlist Erik, not exactly, but in the longer view quite likely better than my obviously narrower views. Count me in the "yes" column. ;-) Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> <apt> it has been said that redhat is the thing Marc Ewing wears on his head. ------------------------------------------------------------------------------ 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
