On 21.03.12 08:29, dave wrote: > 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.
If you're willing to use a more human readable form of gcode, then the translator in the works already has "#include" capability. (The testsuite currently comprises two files, with one included by the other.) That provides two methods of chaining files, already: a) List any number¹ of #includes in a main program file, which mainly serves to control the sequence. b) Put a #include at the end of each file but the last, to pull in the next file. To confirm, I've just paused to copy a bunch of commands into a third file of test input, and added a #include to the second (and removed its "End" (M2)). That chaining method also works fine. That means we can start without the "#nextfile" command, which I floated upthread. We have the functionality already. But at some point, linux will complain about too many file descriptors being opened by the process, if we nest too deeply. So we'll add a "#nextfile" command soon, to let the translator close the previous file descriptor, thus removing the limitation of approximately 20 files, IIRC. With standard LinuxCNC gcode issuing from the translator, there's no way for the LinuxCNC interpreter to know what tricks we are pulling ... or limit them unduly, I expect. Erik (Who needs to get back to adding subroutine translation. If the first cut of this thing is to be finished soonish, something needs to be added each day. :-) ¹ The input file stack should allow more or less any combination of both methods, but I'm not stopping to test that now. Two methods ought to do for a start. -- A computer is like an air conditioner, it works poorly when you open Windows. ------------------------------------------------------------------------------ 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
