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
--
Gcode needs bringing up to date. We no longer need cater for paper tape.
- Dave Caroline, on emc-users ML.
------------------------------------------------------------------------------
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
