Calypso CNC User Forums

I am new to cnc, so this is likely user error.

I referenced the machine and moved the table and spindle to the position I wanted for a tool change. I used the button on the tooling page to set the TC position to the current machine coordinates.
With TLO's set to 0 on all tools, a tool change works as intended and the machine stops at the same machine coors as is set for a TC. As an example x=5, y=5, z=-5.0 (machine coors)

However, if I now enter say TLO = +1, and TLO is now active, the same tool change in the Gcode now stops at x=5,y=5 but Z = -4.0 (in machine coors).

I had assumed that the TC position was an "absolute" so that the machine would go to exactly the same location regardless of the TLO for the current tool. But thats not whats happening and tool changes
don't really work when they are relative to the tool length. I am assuming that this is user error, either in my understanding of what the tool change position is, or in some option that is causing
the tool changes to NOT stop and the actual machine coors I set.

If anyone could straighten me out on what I am doing wrong, I would be greatly appreciative.

Bruce

Hi,

bprager wrote:I am new to cnc, so this is likely user error.

Just a little misunderstanding of what a TLO is and how they work in conjunction with the offsets between Machine Coordinates and Work Coordinates. Let's see if we can give you some additional concepts to help out...

bprager wrote: I referenced the machine and moved the table and spindle to the position I wanted for a tool change. I used the button on the tooling page to set the TC position to the current machine coordinates.
With TLO's set to 0 on all tools, a tool change works as intended and the machine stops at the same machine coors as is set for a TC. As an example x=5, y=5, z=-5.0 (machine coors)

This is correct so far - the TCP (tool Change position) is stored in machine coordinates - i.e. it is a physical location in space that is "anchored" to the machine frame by the home switches (Homing sets the Z0 point for each axis in machine coordinates).

bprager wrote: However, if I now enter say TLO = +1, and TLO is now active, the same tool change in the Gcode now stops at x=5,y=5 but Z = -4.0 (in machine coors).

OK, between Machine coords and Work Coords, there is a transformation. Math wise the transformation maps from MC to WC. This is usually called a "work coordinate offset". The common name is a bit of a misnomer in that people tend to think of a offset as a simple shift (but the general transformation could also include rotations etc).

For now we'll stick to a simple shift. Let's assume the machine is positioned at MC X=5, y=5, Z=5 (your example).
Take a look at the upper panel in a MSM WC offset page. The rows of the panel are literally showing the equation that is used to convert between MC and WC. The total offset is actually composed of a couple of different offsets that Mach combines to get the total offset.

Use the MDI line to do G53 X5 Y5 Z5 - that will put the machine at MC = 5,5,5
As an exercise, let's set all the offsets = 0. We should expect to see the panel showing that MC = WC for each row of the panel after we do that.

use MDI to select G54 - G54 selects the G54 WC offset set. There are multiple sets that can be used, I'll use the default G54 for this example.

In the WC offset columns, select each DRO (selectable DROs have a green inner shading in MSM) and set the offset value = 0. Remember to hit the enter key after each entry to set the value. The WC offset column should now all = 0.

Now let's clear the G92 offset column.
This time we'll use the MDI line -
Use the mdi line and enter G92.1 - this tells mach to clear all the G92 offsets. The G92 column will now be all 0. You could have done this via setting the DRO values as above, I thought I'd just use on direct entry example and one gcode via MDI example. (G10 could have been used to do the WC offsets from the MDI line).

Now all the X and Y offset should be = 0.
Use the MDI line to enter G49 to cancel any TLO that may be active for Z.

OK, you will note that MC = WC for each axis. That is what you'd expect when all offsets (shifts) between them = 0.

bprager wrote: However, if I now enter say TLO = +1, and TLO is now active, the same tool change in the Gcode now stops at x=5,y=5 but Z = -4.0 (in machine coors).

This is correct. I think what you may be missing is that a TLO value really is used to position the machine such that the control point of the tool (generally the tip of the tool on the Z axis) will be at the same Z level IN WC (but not in MC).

Continuing on from the above example, I'll assume you have tool #7 mounted and there is a TLO value of +1 for the TLO entry in the tool table for tool #7. (If you have a different tool number you were testing with, just use your # in place of my example #7).

Use the MDI to turn on TLO for tool #7. enter G43 H7 in the mdi line.
Now look at the Z line in the offsets panel - The MC value will be the same (G43 does not cause machine movement), but the WC value will be different by exactly the amount of the TLO value.

If the TLO were = +1 the WC value will now be +4 instead of the previous +5. The equation in the row will always balance and (always)
WC pos = MC pos - WC offset - G92 offset - TLO.

The machine was not commanded to physically move, so the MC can't change. But we added in the TLO avlue for Z then we turned on TLO, so the WC value had to change.

This is what you want and how TLO values work. If you are making a part, it is a common convention to use the top of the stock as WC Z0 (Note that is WC, not MC Z0). With TLOs you can just mount the tool, turn on TLO and tell the tool to go to WC Z0. The tip of each tool will end up at WC Z0 (the top of the part), and each toll tip will be at WC Z0 - but the MC Z for each tool will be different as each is a different length and thus will have a different physical length, different TLO value and hence will require a different MC Level in order to get the tip placed at WC Z0.

There are detailed pics and text that walk thru this in the MSM mill user manual - see section 5.2 for more than you probably wanted to know about TLO and the different techniques for setting TLO values.

bprager wrote: I had assumed that the TC position was an "absolute" so that the machine would go to exactly the same location regardless of the TLO for the current tool.

The TCP is absolute - in MC - but the TLO is used to offset in Z for TLO so that the WCZ ends up constant as tool lengths change.

bprager wrote:But thats not whats happening and tool changes
don't really work when they are relative to the tool length. I am assuming that this is user error, either in my understanding of what the tool change position is, or in some option that is causing
the tool changes to NOT stop and the actual machine coors I set.

If anyone could straighten me out on what I am doing wrong, I would be greatly appreciative.

Bruce

Let me know if this helped clear up some of the fog or not.
Dave

Thanks Dave. Yes, it helped. I was "somewhat" aware of how the offsets work, but thought that the tool change position would not use them making the machine always end up in the exact same orientation.
The problem that I hit, was I set the TCP with TLO's of 0. I positioned the spindle left,front, mid-level height. Now I mounted a probe tool which has a long TLO. You can figure what resulted.
Since TLO's were applied, the machine went to the position I wanted, and then went way up to try and bring the tool tip to where I wanted the spindle bottom to be. Hit the limit switches of course and
caused the confusion. I could see from the coors that the "change" was the TLO, but the confusion I think, is that I assumed I could position the machine as I wanted, x,y,z and then thats where it would go, I chg
the tool, etc. I realize now, that using TLO's, I assume??? that I have to set the TCP based on the tallest tool, setting the Z so that the tool leaves the spindle safely below the limits. Then any other tool will end
up at the same tip height, and the head will not hit the limits. Or is there a way for TLO's to be turned off at a tool change so that the head position is always known in Z?

Or am i still confused? (likely......)

BTW - as a newbie, I find the MSM screens a massive improvement on Tormachs or std Mach3. Run,Pause,Stop I understand - compared to Cycle Start, Feed Hold and Reset, not to mention the std symbols you use on the buttons. Its also nice to see high quality graphics with round buttons, not everything square!
And please thank the programmer who put in the safety check for a probe being mounted and you accidentally issue a spindle start command. I greatly appreciated seeing a message of Probe detected. Spindle Start commands ignored. rather than seeing my cable ripped in two (which would have happened using the std software I started with). You say you are designed for User Friendly, and you are!


Just a quick question - Why wouldn't you want the TCP to NOT use TLO's? I understand for machining, TLO's are critical, but when you want to change a tool, wouldn't it be advantageous to have a completely stable TCP, that is exactly the same in x,y,z for every tool? (pardon what is probably an dumb question, but I had to ask)

Thanks

Bruce

Hi Bruce,

bprager wrote:Thanks Dave. Yes, it helped. I was "somewhat" aware of how the offsets work, but thought that the tool change position would not use them making the machine always end up in the exact same orientation.
The problem that I hit, was I set the TCP with TLO's of 0. I positioned the spindle left,front, mid-level height. Now I mounted a probe tool which has a long TLO. You can figure what resulted.
Since TLO's were applied, the machine went to the position I wanted, and then went way up to try and bring the tool tip to where I wanted the spindle bottom to be. Hit the limit switches of course and
caused the confusion. I could see from the coors that the "change" was the TLO, but the confusion I think, is that I assumed I could position the machine as I wanted, x,y,z and then thats where it would go, I chg
the tool, etc. I realize now, that using TLO's, I assume??? that I have to set the TCP based on the tallest tool, setting the Z so that the tool leaves the spindle safely below the limits. Then any other tool will end
up at the same tip height, and the head will not hit the limits. Or is there a way for TLO's to be turned off at a tool change so that the head position is always known in Z?

Or am i still confused? (likely......)

The TCP is in machine coords & in machine coords there is no such animal as a TLO. Also, the control turns off TLO when it starts a tool change sequence - which makes sense when you think about.... the TLO for the tool being removed is of no use, and we can't know a TLO value for the tool not yet mounted - so NO TLO is the only state that makes sense.
For a vertical mill, most folks set the TCP to be at the top of Z travel, that way you have all the physical Z travel avail for mounting the tool.

bprager wrote: BTW - as a newbie, I find the MSM screens a massive improvement on Tormachs or std Mach3. Run,Pause,Stop I understand - compared to Cycle Start, Feed Hold and Reset, not to mention the std symbols you use on the buttons. Its also nice to see high quality graphics with round buttons, not everything square!
And please thank the programmer who put in the safety check for a probe being mounted and you accidentally issue a spindle start command. I greatly appreciated seeing a message of Probe detected. Spindle Start commands ignored. rather than seeing my cable ripped in two (which would have happened using the std software I started with). You say you are designed for User Friendly, and you are!

That programmer would be me - don't ask why I added that feature... it was not a real good day in my shop when I decided that turning on the spindle with a wired probe mounted was a bad idea...

bprager wrote: Just a quick question - Why wouldn't you want the TCP to NOT use TLO's? I understand for machining, TLO's are critical, but when you want to change a tool, wouldn't it be advantageous to have a completely stable TCP, that is exactly the same in x,y,z for every tool? (pardon what is probably an dumb question, but I had to ask)

Thanks

Bruce

Nope - the TCP is where the spindle nose is positioned in MC - it is NOT where the tip of the new tool will be. The TCP position is stable - and the tip location changes with the tool length.

I suspect you are thinking that a newly mounted tool should have a magic TLO value applied at the instant it is mounted but that is not how G-code works. When a tool is mounted, there is no TLO value and G-Code definition says that TLO is not turned on until a G43 Hx is executed. Thus one has to realize that the M6 command does not apply any TLO value as part of the tool mounting.

If you wanted to have TLO on at the same time as when a tool is mounted, you could program T# M6 G43 H# in a single g-code block - or at least you can if you are not running mach.... mach has a bug that causes that single block combination to break (See MSM release notes section 4.27. IN gneral you may want to read thru the release notes section 4 as that is a long list of reported, and not fixed bug in mach - at least if you know what they are you can try to avoid them).

Dave

Thanks Dave, and BTW - thanks for that safety code:)

I thought I had it, but I must be missing something. You said TLO is disabled during a TC, which makes perfect sense to me, you don't want the mill moving up and down - just going to the TCP which if you put it to max Z, gives you max room.

But that got me confused as to why did the mill NOT go to the MC of the TCP when I set TLO <> 0? If TLO = 0, then the mill moved exactly to the MC I defined in the TCP DRO. After the TC ran, I would look at the coors in the DRO, (set to display MC NOT WC which I knew incorporated TLO) and the MC of the machine and the MC set for the TCP matches.

Then I set the TLO for the tool to +1. Moved the machine back to the starting position, and triggered the TC. The mill then went to the TCP, but now moved 1" up. The DRO now showed the the MC of the mill was not equal to the MC of the TCP, it was 1" different. If TLO is not being used during a TC, then shouldn't a TC with a TLO =0 and a TC with a TLO of 1 be the same thing? The mill should move to exactly the same position no matter what TLO the tool has, since TLO gets turned off for the tool change?

Maybe the problem is in the G-code, its supposed to be a simple test program that assumes no TLO's are set.

Sorry for the confusion and thanks for all your time.

Bruce

Dave, I just finished doing a bunch of testing and something is a bit odd. Your explanation was very clear and it made perfect sense.
So I set the TCP, set up a few tools with simple TLO's of 1, and moved the mill to a std position. Then I typed M6T1. Mill worked perfect, moved right to the TCP. I turned on TLO, redid it, and it worked perfect again. So I set up the mill and ran the test g-code. It moved to the TCP (as defined) , paused, then moved up the TLO of 1 and the MC of the mill wasn't the TCP MC, it was different by 1 in Z.

So I just typed in M6T2 as all the tools were set to a TLO of 1. Now since I was "at" TCP, mill shouldn't have moved, but it went down 1 in Z and now the MC coors matched. So something in the code is doing something that I can't see. The code is:
G20
G00 G17 G40 G49 G80 G90
T1 M06 G43 H1

Does that explain anything?

Bruce

Congrats, you have hit a known, documented, reported, verified but NOT fixed Mach bug -
All I can say is that it would be nice (and refreshing) if reported mach bugs actually got fixed!

To work around the bug, change
T1 M06 G43 H1
into two sequential lines
T1 M06
G43 H1

Then try it again.
This is the mach bug I referred to in the prior post - read item 4.27 in the MSM release notes for more info.

You can feel better by knowing that what you saw happen is incorrect - it's mach that is crazy in this specific case and not you

BTW, If you use a post processor in a CAM program, check it to make sure it does not try to output that single combined tool change and TLO application code block for a tool change.
Dave

Ah, bless you. I thought I was really losing it. Your posts were great and I felt sure I now understood it. Then I ran the code and it moved to the TCP + TLO.

I looked at the code and couldn't see where it said to move again. Thanks for clearing this up and also helping clear up how TC is handled.

Thanks!!

Bruce

Bruce -

bprager wrote:...Then I ran the code and it moved to the TCP + TLO.

In case you are curious about what mach did when making this particular piece of ugly sausage....

What most people call a line of gcode is formally composed of a "block" (a block looks visually to be a line in the gcode file) and words. The Words are the things inside the block (Ex" G43 is a "preparatory" gcode (that is what the G means) and it's code 43, which happens to be "apply TLO".

When the single block example of "T# M6 G43 H#" is executed by mach you can literally crash the machine in a spectacular fashion. There is specified precedence between words that determines what order words within a block are supposed to be executed.

For the this block, the M6 is supposed to be started first, FINISH, and then the G43 H# is executed.
At the start of M6, TLO gets turned off (equiv to a G49 in gcode).

The bug is that mach is not waiting for the M6 sequence to finish before doing the G43... that's real bad news. The bug is causing mach to run the M6 and the G43 words in parallel in time.... so the G43 TLO value gets applied at some random time during the M6 actions - and when that happens depends on what thread got the CPU for how long etc.... effectively mach is changing the TLO value at a random time DURING the M6 sequence. You can see how that can crash the machine in rather spectacular ways.

Splitting the single block into two blocks forces mach to complete the first block (with the M6) before it starts the 2nd block (with the G43) - yielding the behavior that mach should have done for the single block case.

Dave

Dave, I really appreciate how you take the time to so completely answer questions, that in most forums, would get a - Learn what your doing and ask again.

Not only do you respond quickly and thoroughly, but you have a not-common ability to answer in real english, not geek-speak or language that a expert would understand.

Having spent 30+ years writing user programs, I appreciate the difference and the ability.

By any chance, did you help write (or write) the MSM users manual? It has the same clarity (and humor) that is in all your posts.

It was worth buying MSM just for the manual and to get the resources of this forum. Its taught me a lot already including how much more I need to learn.

But the best part, this is fun!

Bruce