On Wed, 21 Mar 2012 19:24:52 +1100 Erik Christiansen <dva...@internode.on.net> 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] 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 > 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? > > > 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.) > > Even if we start with something basic, it can be tweaked as we go > along. > > Erik > Hi all, "It is obvious that", oh, what a way to start a statement. ;-) Anyway, I think we need a way to queue up a series of programs; in other words a facility to do open and run from a sequential list. Dave ------------------------------------------------------------------------------ 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
