You probably got directed here after asking: "Why can't I type a tool # into the current tool DRO in MSM?
Ah, now you've done it.... you've triggered "Dave's Mach rant #23"....
When running Mach without MSM, if you type a tool # into the current tool # DRO, it will look as if mach has somehow magically done a tool change. The DRO now says the new T# and you think things are fine..... but they're not.
Mach3 has numerous internal logic flaws in this area and they drive one batty if you get into trying to figure out their details: "Been there, done that, have the tee shirt". Suffice it to say that if one uses the (dubious) method of changing the DRO # for current tool, that only part of mach treats it as if the tool was changed and other parts get internally confused. When this happens some mach API calls then start to return bad results - and this crashes scripts in weird ways. When I first started running into the bugs in this area, the flaws were reported; but they (like many bug reports) were not fixed.
That is not good as these bugs can leave mach is a broken state that is dangerous...
If you execute this gcode sequence:
T6 M6
G43 H6
you now have the active TLO set to the entry in row 6 of the tool table. Note how I phrased that last sentence.... I did not say "the active TLO is the value for tool 6". The distinction is important! There is no requirement in gcode that the active H# = the active T#.
Using H=T is a common convention, but it is NOT required.
This sequence is just as perfectly valid:
T6 M6
G43 H112
The active TLO value is the value from row 112 of the tool table.
Problem 1: Mach uses the tool table to store TLO values.
This is confusing. it is much more logical to store TLO values in an independent TLO table. Then you are not tempted to equate TLO table indexes with Tool table indexes. Why does mach do this? Because when that part of mach was written by Art back in the depths of mach time, Art did not understand tool offsets (as Art told me himself once upon a time). Early on, he thought there would only ever be one TLO used for one tool. .. and that assumption lead Art to decide to have "mach help the user"....
To "help", Art created the logic that when you change the current tool# DRO directly, mach tries to guess and set the TLO to "match".
The problem is that this screws up real gcode programs.
Problem 2: Part (but on all) off mach tries to short circuit tool changes when the current tool DRO is changed.
Consider this sequence:
G49 - now there is no TLO active
T4 M6 - we've changed to tool #4.. and there is STILL NO TLO ACTIVE. This is how gcode is defined to operate - and it is how the gocde part of mach does operate.
(side note: Mach took it's gcode interpreter from EMC, and EMC when implemented by NIST, implemented RS274 as it's gcode dialect. Then Mach started changing (usually without documentation) how it handles syntax and semantics for gcode - so there is no, known, up to date gcode reference for mach 3).
Now someone types "4" into the current tool DRO -
We just typed in the current tool number - you'd think that should make no difference as nothing changes right? wrong...
When you do this, Mach changes the TLO from inactive to active and sets the value for TLO from row 4 of the Tool table.
DANGER: Mach has just changed the state of the gcode interpreter behind the back of the operator and gcode programmer. This is bad news and a terrible thing (IMHO) to have done. Mach is now likely to cause a machine crash. Mach is saying that it knows better than the gcode program what the TLO value should be. B.S.
A cnc control runs a gcode program and gcode programs are inherently state-full. Correct operation of gcode depends on the internal state of the control being what the program set it to.
Let's consider an example of using two offsets for a single tool. Think about a slitting saw. It's not uncommon to use two offsets: one to align one side/edge of the saw blade and one to align the other. So if the saw is Tool # 10, we might have one TLO value in the TLO table in entry 17 and the other in entry 18.
Now do these actions via MDI and the current tool DRO - you will crash the machine or at min cut in places you did not want....
T10 M6
G43 H17 - now we're all ready to cut with the saw....
Current tool DRO -> 10.... whoops TLO just got changed - to some value from row 10 of the tool table!
Since the TLO handling operation of mach was not going to get fixed until mach 4 (so Brian told me about 4+ years ago when this first came up), I did the only thing I could do. in MSM, I disabled the ability to type a value into the current tool DRO and I forced MSM users to use MDI to change tools.
This avoided the bugs in the mach internal code that handles current tool DRO value changes. By doing this it
a) removed the ability to use the broken parts of the mach logic associated with the current tool DRO), and
b) made all tool changes work correctly (at least wrt to TLO state and values).
When that was first done, the idea was this could be revisited when mach 4 was released (which was "any day" then, and it's still "any day now" ... 4 years later... (FYI, it was 4 years in 2013))
Ok - rant off.
What you were used to doing with the old tormach (mach 2.6 release level I think) software was using the current tool DRO.
Now at least you may have a better understanding of why that does not work in MSM.
sirbean wrote: Seeing how you have a good understanding of the G-code. If we are already in G43 , why must me add it with every tool change? Example would be this . Tool change M6T2 H2 does not work where as M6T2 G43 H2 does? You don't have to answer , but when you give me the chance to learn I will jump at the chance. Thank you again for the very quick answer to my problem and for and great answer.
You have to give the G43 command because that is how the syntax of gcode is defined.
Think of it as the G43 being the command and the H# being the parameter for the command.
Consider this sequence:
T5
<more lines of gcode>
M6
The T5 does not change the tool. T5 tells the control to prep Tool #5 to be ready to be used. That can take some time to do on older machines - it may involve rotating a tool changer to get T#5 into position to be loaded into the spindle. So the T# is often executed way before the M6. M6 is actually "load the next tool # as specified by the last T# word that was executed".
This allows parts to be made faster than doing the (simplistic and time sequential)
T5 M6
A G43 by itself should (I think) be a gcode error - no H (TLO) offset index was supplied - so the control can't know what to do.
But Mach does not error out, instead when the program says "G43", mach does "G43 H<current tool #>" - again mach is NOT doing what the gcode programmer programmed.
Yet for reasons only those with access to the mach souce code may know, H2 alone is an error.
If you subscribe to the "mach should guess" camp then maybe mach should have turned "H2" into "G43 H2" - ah but what if the current T# is not = 2 ?!? Or what if you wanted G44 instead of G43?
You can now probably tell that I'm firmly in the camp of "Computers should do what they are programmed to do and should never guess or think they know better than the programmer!". I feel particularly strong about this when talking about machines that cut off limbs just as easily as they cut off steel. I really don't like CNC machines that create "surprises".
If you want to learn the details of how most CNC controls work, I recommend that you pick up a copy of Peter SMid's "CNC Programming handbook", third edtion. It's the best reference I know for Fanuc control gcode which is the closest thing to a default standard for gcode that the industry has (each control brand has some differences). Smid's book will tell you all about weird gcode details like the ones I've talked about here.
Dave