I had a problem with my controller last night.  I loaded a program, and it ran without incident.  I put a fresh piece of stock in the vise, and hit “Cycle Start” again.  It ran through the first tool without any problems.  After the tool change to the 2nd tool, the spindle speed changed to 250 rpm, and all three axis moved to 0,0,0, ignoring the tool length offset, which crashed the tool into the vise.

This happened to me once before, several months ago.  Since then it has all operated as normal.

I don’t know how easy it is to tell in the picture, but the last commanded line was X.0223 Y-.5 S2600  and you can see on the display X&Y are zero and the speed is 250.  The Z shows a large number because I jogged the Z axis up so the tool was out of the vise. 

That is an unusual way to call the tool change . Mach3 can be sensitive to such things at times.

It is best to cancell all tool offsets

G40 G49    (cancell offsets so there are no surprises)


M6 T34      ( Change tools )

G43 H34    (Reassign Tool Length Offset)

G0  X0Y0 Z1          ( move to new start position giving Z room to comp)

G73 ***************************xx 



In your code you applied tool comp WIth G43 T34 H34 M6  Which sets the comp to the H34 value

THen as the code restarted you changed the COmp to H00 (tool 0)  Which would set it back to 0 comp

What would the CB code be for the M998 ?


\
(;-) TP

Terry, it's the Tormach version of Mach3, and their M998 macro.

AH ok Tormach, Then it would be best to ask Greg over at Tormach that question as they have their OWN version of Mach3 and their own screen sets and Macro sets.

(;-) TP

This is a repeatable problem.  Here is a video of it. It runs the first tool fine. As soon as it starts the spindle after the tool change, if you accidentally click "Cycle Start" again, it moves all axis to 0,0,0, sets the spindle to 250, and seems to change the feed to 8 ips.

Obviously this isn't anything I would ever do intentionally, but it seems like somethings that would be easy to fix in the Mach 3 code.

Sorry about the video quality.

http://youtu.be/aIbrIsWhAV0

post a copy of the Program file I will test it here on a standard version of mach3.

I believe your problem is a Tormach related problem in either in their ver of mach3 or macros or toool change routines(macros).

(;-) TP

I just ran the program 8 times in a row without incident, so I'm sure it was related to the accidental double-click.  It would be interesting to see if it happens to other versions of Mach 3. 

The steps to recreate the bug are somewhat specific.  It isn't a true double-click, but the 2nd click has to happen while the spindle is still getting up to speed.  Once it is going, another click doesn't cause any problems. 

I don't think it is related to my G-Code, but it is attached. 

Here is the same code without the H00.  I'll test it tonight when I get home to see if it has any affect.

Hi,
I believe you have hit a known bug in mach 3 (known, reported, but not fixed).

From the MachStdMill release notes section that documents known mach bugs:

4.27   Mach handling of T#M6G43H# in a single block
There appears to be a bug in Mach when it is asked to execute a single block of gcode that contains T#M6G43H#.

It appears that mach is processing the G43H# part of the block before the M6 portion of the block has completed.

In the Mach Gcode documentation, it says that mach will do the M6 code before the G43... but this is an area where weird stuff happens and it's been problematic for Mach in the past. Mach implements the M6 as calls to user scripts and it appears that Mach is not waiting for the M6 scripts actually end before it starts the G43 action.

The result appears to be that Mach can do the G43 in parallel with the M6 sequence and thus the TLO gets (re)applied part way thru the M6 processing - that really upsets  the MSM M6 handling code as it turns off TLO and then TLO gets turned on again out of left field...    The symptom is that sometimes T#M6G43H# will work and sometimes it will cause a tool crash. The exact result each time depends on when different processes get the CPU...

Recommended Work Around:
Place the T#M6 and G43H# into separate blocks (separate lines). This removes the potential for parallelism as Mach is forced to finish one block of code before it can to the next one.

If you are using a CAM post processor that creates a single block for T#M6G43H#, change the post processor to emit two separate blocks (lines) of gcode instead.

Verified on Mach 3.43.37

Dave

I just tested it and what you have listed above isn't the problem.  I don't know if this bug has been reported or not.

If you hit "Cycle Start" after M3, and before the spindle is up to speed, it causes the machine to move to 0,0,0 and the spindle to run at its slowest speed.