Hi Dave,

With your help and the updates to MSM and Mach I have now got MTM working the way it should.  I've made changes to my post possessor to make good use of this and all is looking good but for some reason when I run the G-code it returns to the start of the code after a tool change.  I have TC Auto TCP, Master T Mode and TC Auto TLO on and the code from my post is

 N1 G21 G40 G49 G54 G80 G90 G91.1

(JOB 1  SLICE CUT PLANAR)
(FEATURE SLICE PLANAR)

N2 T3 M06
N3 G43 H3
N4 M08
N5 S24000 M03
N6 G00 G90 G54
N7 X0. Y90.31
N8 Z19.
. . . . . .

I have beta 5 with Mach R3.043.016 and SS.

Code runs fine if I Set Nxt Ln: to the one after the tool change until the next tool change, any ideas?

Calum

Calum,
Is it really rewinding or is it stopping on the tool change?

I can't run your code fragment with MTM and ATLO at the moment as I have the mill down for a mod and I need the TCP TP to play ATLO games.
But I tried it with just ATCP (No MTM & No ATLO) - and I'm seeing this happen:

start the code - goes to line N2
mach executes the M6,
mach calls M6start, the M6start code is run (M6start is what swaps us to the tooling page).
The machine gets to the TCP, I press the cycle start buton on the tooling page
mach sees the button action and calls M6end.
M6end finishes and we are at the run page (which is where I was when before the TC) -

At this point the code should be running again - but it is not.
Instead what I see is that the code is has not been restarted by mach - it is just sitting on the N2 line.

An "Extra" click of the cycle start button on the run page, will get the code to continue....

here is another test case I used that shows the problem to me:
G90 G00 x0 y0 z0
x1 y1 z-1
t1 m6
g43 h1
x2 y2
t2 m6
g43 h2
x3 y3

Mach fails to restart the code after each tool change.
So, I'm not seeing a rewind, but I am seeing a "it did not continue running from the TC" problem.

This particular Mach problem has been "fixed" multiple times in the last couple of months- yet here it is again.
I suspect that whatever was done in 3.43.16 to stop MDI from causing a cycle start, has reintroduced this bug.

I'm not yet sure if there is only 1 problem here or two - so I need to confirm if you are seeing the same problem I am, or are you really seeing it rewind?

If it's really rewinding, the gcode window's highlighted line (for your code) will be on N1 in and not N2 after the tool change.

Dave

Hi Dave,

It definitely rewinds for me, both my code and your test code return to the first line and stop!

I also had something weird happen after I ran my code as a test I loaded your code, had a couple of false starts then when it got to the tool change all 3 axis started moving when it was trying to do the TLO.  I restarted MSM than ran your code which returned to line one after the ATOL.

Calum

Calum,

let's try to narrow down to see what the problem depend on.

1) having more than one axis move when a G31 is issued to mach sounds to me like a bug that Brian has been looking for for a long time.  When I experienced that once, it seemed to be a corrupted XML file. I found that creating a fresh XML made the problem go away.
Before you do that, I would like to see if we can get some information about the bug....
Please save a copy of the XML in use when you saw multiple axis movement.
If you can make the multiple axis movement happen again, when it does, stop mach and close mach.
Then find ProbeDiag.txt in the mach dir and  please email the XML, ProbeDiag and as detailed a description as you can as to what you saw happen.


If the multi axis movement is no longer happening, and the rewind problem is still reproducible -

2) Lets try to determine if the rewind is a function of one of the MSM options:
We'll use my little test case code for this -
turn off AutoTCP and MTM and AutoTLO
run the test code - is it rewinding now?

If not, add back the options one at a time, checking each option:
AutoTCP: causes rewind?
MTM: causes rewind?
AutoTCP + MTM: causes rewind?
AutoTCP + MTM + AutoTLO: causes rewind?

Dave

HI Dave,

1) OK I'll try to capture the environment next time I see multi axis moves, it seems OK since I restarted Mach but it has happened a couple of times before.

2) I turned off AutoTCP, MTM and ATOL, code ran fine until I re-enabled ATOL where the code rewound after returning from the tool change.  I did a manual TLO measure while doing the tool change with everything off but and the code rewound when I returned from the tool change, seems to be something to do with the TLO measure.

1 revisited) The multi axis move happened while I was doing the above so I will send the XML and log file to you as well.  I had to restart the computer to get a copy of the log file as it was still open after I shut down Mach.

Cheers
Calum

Calum,
I think I found the ATLO problem you are seeing.
I'm a tad embarrassed to say that it was a 2nd instance of the bug I had fixed before where a value was not corrected for metric machines vs imperial machines.
(The code was only insisting that for Auto-TLO that the position at the TCP be within 0.0001mm...    )

I've emailed you directly a revised version of the probing library.
Please try the MTM Auto-TLO again with this probing library - I think this should fix the problem - If it does, please let me know that it is fixed.
 
Dave

Hi all,
An update on this one -
Calum managed to find two separate bugs - one in MSM and one in Mach. (I bet he feels so special   )
He has confirmed that the test revisions we sent him fix the problems and the corrections will be in the next mach and MSM update.

Dave

Thanks Dave,

I don't feel so much special more privileged to be able to help out with this great work that you and other are doing.

I've been using this config all weekend and everything seem to be going fine.  I'm waiting on my probe to arrive so that I can give probing a go.

I have a couple of suggestions that would make things a bit easier for me at least.
1) Would it be possible/practical to be able to enter the thickness of the mobile TP and the gauge block?  I use both, gauge block for ATLO and mobile TP to set WC Z zero.

2) Would it be possible to have the Set Z zero arrow on the WC Offset Touch Off tab made into an action button that would move Z down to the mobile TP on the work?  I can achieve this by using the TP as a home switch and setting the offset as the TP thickness but this make the MC Z = WC Z, this is the way I have been using Mach until I found MSM with MTM.

3 )Would it be possible to get the PTL for the master too from Tooling tab where it is entered or measured when we go to set TCP TP MCz on the Settings tab?  The way I have been setting up my machine is-
   Go to a random x, y ,z and Ref All (all install some home switches soon)
   Move to WC x, y & z zero and zero these
   Move to TC position, load the master tool then measure its PTL.  This updates the Master PTL on the Tooling tab
   Then go to the Settings tab and Set TCP TP MCz.  This requests the Master Tool PTL which was captured in the previous step.

I may be using this the wrong way but this seems to work for me.

Calum

Hi Calum,

2) Would it be possible to have the Set Z zero arrow on the WC Offset Touch Off tab made into an action button that would move Z down to the mobile TP on the work?  I can achieve this by using the TP as a home switch and setting the offset as the TP thickness but this make the MC Z = WC Z, this is the way I have been using Mach until I found MSM with MTM.

If you click the "Probe Z-" arrow on the probing page it will do just what you want.   
The probing page handles "probing events" - i.e. moving until a probe event is seen by mach and the G31 movement is stopped.
Neither mach nor MSM know if the signal came from a probe or a touch plate..... or the push button I have wired to the BoB in my test setup in the office... A trigger is a trigger.
If you have Settings-common "TLO G-BLk is TP" on, you can "probe down to the mobile TP"....

1) Would it be possible/practical to be able to enter the thickness of the mobile TP and the gauge block? 

Hum, It is set up with the assumption that for a GBlk  one uses either a plain GBlk or a TP (which gives the ability to probe to the TP/GBlk). You can switch between a GBLk and TP, or for that matter between GBLk of different heights, or TPS of different heights (thihcknesses) by changing the DROs & button settings on the settings-common page.
The basic requirement is to change the data for the height of the GBLk/Mobile TP whenever the height of the block being used changes (I.e. whenever you use a different block).
MSM would still need to told whether the GBLK is a TP or not - as it can't "find out".
I suppose there could have two DROs, one for the GBLk and one for the "GBK is TP = mobile TP", but uh, I'd have to redesign the setting page to fit in it....     
Honestly, I'd rather not unless I hear a lot of support/requests for this.
 

I use both, gauge block for ATLO and mobile TP to set WC Z zero.

I'm confused by this -
Auto-TLO as part of a tool change, requires the use of the TCP TP, which has to be in a fixed position under the TCP.
That action does not use the mobile TP (and can't as the TCP TP has to be at a known, fixed, physical location).
So, I'm not following when you say you use the "...gauge block for ATLO ..."

3 )Would it be possible to get the PTL for the master too from Tooling tab where it is entered or measured when we go to set TCP TP MCz on the Settings tab?  The way I have been setting up my machine is-
   Go to a random x, y ,z and Ref All (all install some home switches soon)
   Move to WC x, y & z zero and zero these
   Move to TC position, load the master tool then measure its PTL.  This updates the Master PTL on the Tooling tab
   Then go to the Settings tab and Set TCP TP MCz.  This requests the Master Tool PTL which was captured in the previous step.

Wow, I don't think that should work at all -

You can't use the TCP TP (before MSM is taught the MCz location of the TCP TP) to measure the MT PTL. The measurement will not be accurate as the TCP TP is not known.   If appears you are then using the measured MT PTL to locate the TCP TP in Z.
This is a boot strap problem.

The "locate the TCP TP in MCz" is a one time, special process. IT is needed whenever a TCP TP is installed or moved.
MSM has to start with some known data to accurately locate the TCP TP. The process requires that the machine know where it is along the MCz axis. Hence the requirement that the machine be referenced; referencing anchors the MC axes to the home switch physical location. When Z is referenced, MCz0 is anchored to a known spot - which can be found each time the machine is started and referenced.

Next MSM needs a known, calibrated measuring stick to measure from MCz0 to the TCP TP surface.
The setup process has you (offline) measure a tool to measure from MCz0 to the TP top surface. This is why the special setup process asks for hand input of the PTL of the tool being used to make the measurement.

With those two pieces of information in hand, MSM probes down to find the TCP TP surface. The MCz location of the TCP TP is then stored. The location is calculated from MCz0 and the hand input PTL of the tool used to make the measurement.
(the tool used to make the measurement is not any particular tool, not the MT, nor anything else).

From the time the TCP TP is located ***going forward in time****, the TCP TP is assumed to not have moved. This allows the TCP TP surface's MCz (in reference to MCz0 as set by the home switches) to be used to measure a tool's PTL as part of a tool change (This is the TC Auto TLO option). 
AFTER the TCP TP is located, it can be used to measure the PTL of the MT - but not before.
In MT mode, for tools that are not the MT, MT PTL - measured PTL gives TLO for the tool.

Dave

Hi Dave,

1) I wasn't using the “Probe Z-” because I have an SS and I had read that probing didn't like a zero diameter.  I have tried it now and all works fine just got to remember the TP offset.

2) No worries I was just being lazy, I'll get the hang of changing the data.

3) No longer an issue now that I know how to use probe Z-.

4) I had a feeling I was doing it the wrong way, thanks for putting me on the right path this is easier.

Here are a couple of observations which you may be aware of -
One of the Wizard buttons on the Load tab blacks out when I load gcode.
The NRH/RH led does not light when a tool is selected, the empty led works fine.
I think the CV Angle on the Settings tab is reading the wrong data from the Mach config, looks more like the CV Dist Tolerance.


Cheers
Calum