The Matrix control on my Mazak (circa 2005/6) has a "manual interruption" mode and a "TPS" mode - both need to wait for an end-of-sequence and don't work in canned cycles. Most interestingly, it doesn't work with G-Code, just Mazatrol, on my unit. I would expect the reason for this is again in the trajectory planner; going backwards isn't really a "planned" event in the majority of controls (less perhaps wire EDM). The TPS, (tool point storage) is a four-point "jog while in pause router" - when in feed hold you move the MPG handle, press the "TPS" button, and it stores the x/y/z/a position. You can do that 4 times. You can then either resume from feed hold, or step backwards through the prior TPS's to get back to your original position. Mazak gets around the modal/non-modal restarts because each sequence in a unit (command in a block) in a Mazatrol program is referenced with the initial offset data and cutting conditions - as a conversational language it isn't spooled g-code text, it's compiled in-line. So in essence, a "restart" is really just running that sequence again, perhaps cutting a bit of air, but only a small amount. I have had it fail, however, and it's an easily reproducible failure that I think will affect everyone and hasn't yet been brought up: Tool length offset has been mentioned - tool radius offset has not. when I change out a worn tool for a new one, I have my table toolsetter check both length and diameter. Typically, a new tool has a greater, if only slightly, diameter than the worn one. However, due to the many ways I write g-code, I let the control only use the length offset. I have a number of tools due to their geometry or the way that I use them aren't appropriate to let the control calculate the radial offset, for it would be incorrect (chamfer tool is a good one, as is a threadmill). I let my CAM program calculate the path offset using the known diameter of the tool, so I can also adjust that offset for special needs and not have the control over-ride it. If I break an endmill, it is unlikely that I will have my finger on the feedhold button and be able to press it at JUST the right moment - which means the machine is in a position that has not been properly cut. If I then hit feedhold, replace the tool and resume, it will engage into uncut material - there is no backing up a few inches. There will also be a witness mark where the tool cut that likely needs to be remachined. If the workpiece can be salvaged, it is worth re-running the entire machining operation (such as pocketing, profiling, etc - not necessarily the whole job) to make sure the blemish is (hopefully) removed. I think the challenge here is not just of implementation in EMC, but the whole system, including the writing of g-code. I intentionally split my machining into many operations or subroutines that can be separately called so I can rerun a portion, do some gaging in the machine, change or reset tools if necessary - since I'm not a 24-7 production shop, I can afford a few minutes of spindle downtime occasionally. If there is no problem, it runs by itself. If there is a problem, I'm only rerunning certain machining operations forward - and not worried about missing a non-modal. I literally escape from program or tape mode, replace tool, change offsets, restart with a (clean) slate. Occasionally, I'll even re-post entire machining operations as new "programs" and run those. That's the benefit of breaking code into smaller sections - starting in the "middle" is much easier. When I write code by hand, I am typically doing geometric repeats, so macros are the norm. I also have tried to halt certain processes mid-stream and try a tool reset - typically there is a sync fault that leaves a tool blemish, however if i rerun the entire macro/sub etc - that blemish is usually smoothed out, so again having smaller distinct sections of code is beneficial. Who uses macros anymore? A lot of people (commercial production shops) do - a lot that still haven't converted to 3d surfacing, or still prefer 2d prints on paper. Or a shop that has many parts in families - one company that uses macros at their machines and not CAM specifically we've probably all ordered from: SDP (Stock Drive Products) - they were profiled in MMS magazine a while ago - and don't model the latest gear in 3d; they have macros for each product type that they just plug in a dozen different variables and out spits a gear with hub...or not hub....or not gear.....their machine operators are their CAM programmers. When you are in a macro, however, other things can change or depend on sets of variables - if a tool offset is one, a whole arc or succession of arcs can be mis-calculated/mis-referenced due to the minor change. Thus, it comes down to the great possibility that all the capability for moving around and changing numbers during a feedhold (due to tool breakage) won't actually let you succeed in producing a usable part. To be honest, even with controls that do have this functionality, I rarely, if ever find a practical use for it.
Ted. ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
