Short Background:

Threading was fixed some 6 years ago and the min Version of Mach would be 3.042.033.
I am currently using 062 ( haven't done that much threading but so far so good ) and
as Hood said don't use 066.
Should there be slowdown of the spindle Mach will try to maintain the thread lead.
The spindle variation range is approx 10 to 75%, but frankly it's not a sure thing,
and spindle variation should be such that it's a stable as possible for the thread being cut.

I haven't experienced what you describe since I use the threading wizard and also have the
m1076 produce G32 with comments ( default setting in macro Test=true ).

I am not sure what the problem is, don't think it is the m1076 macro / taper and would suggest
you try the following:

Just try the threading but with very small depths of cut and carefully watch what is happening.
That would be the equivilant of a scribe test.Say 20 thread passes. Make sure you are not exceeding your acceleration / velocity settings. Watch the rpm dro for any changes.

RICH

Do some scribing tests. There is write up called Threading on the Lathe in Members Doc's that covers threading. Not sure what you describe is actualy what is happening.........but will say that
what you describe was "similar" to what was wrong with threading a long time ago....not sure what you observe is what is truely happening as it can very deceiving when watching the motion.......

1. Are you using the default lathe screen set?
2. Is the m1076 being used from the 062 download, not a modified one, an old one, or another one located
   in the directory where Mach is installed?
3. What are your turn cycle defaults defaults in configuration for threading?
   config>ports and pins>Turn Options
4. In spINDLE SETUP MAKE SURE "uSE SPINDLE FEEDBACK IN SYNC MODE" IS CHECKED and check Spindle speed        averaging.
5. Open the threading wizard and confirm there is no taper setting value / should be 0.00.
   While there using the values you used for the M76 "Calc number of passes for a check of velocity and    accel.
6. Two simple scribe tests:
   Turn stock to some diameter ( say 2 inches long ),color the stock, move z to at least 3 dia away from    the end and not changing the x axis.
   - do  a G32 commmand via and see if it just scribes a line with no taper
   - do a G01 at same feed rate and see if that just scribes a line
   ie; the only difference between the two is that the g32 implements the use of the index to start the        thread.
7. Scribe using the threading wizard ( Simple Threading )and suggest having the m1076 default to G32          output so you can follow each pass.
   When you scribe do about 20 passes at a "very small" depth of cut.
8. Scribe using the G76 wih same values as in 7. using the MDI and make sure that you have the T with a
   value of "0" in the command.

After above you can move on to actual threading if all is ok.....

RICH

Mach3 has bugs, we know Mach3 has bugs, therefore we have no cause for complaint
with huge apologies to Scott of the Antarctic.

This happened after a crash? It sometimes seems to me that Mach3 corrupts its XML file during a crash.
Go to the Diagnostics page and look under Threading. There is a default value there for Taper, which is used if you do not specify what taper you want.
'But I do specify what taper I want!"
Yeah, but does Mach3 read YOUR taper value at the start, or does it read the default value? In some cases, the value you have specified is only read LATER. I am not saying this is happening here, only that it is worth checking.

If the Taper value on that page is non-zero, set it to 0 and Save Config immediately.

Cheers
Roger

@Rich - I tried all that and all good.  

@rcaffin - I thought you were on to something then because that seems to be exactly what is happening! But the diagnostics screen taper is set to "0.0000" However the program does not crash at all!

Let me outline exactly what is happening:

FirstOp.tap = a few general lathe operations, facing etc and towards the end cuts an 0.75 pitch thead using
G0 X9.95
G0 Z5
G76 X9.0 Z-21 Q2 P0.75 J0.04 L45 H0.04 I29 C1.0 B0.01 T0

PartOff.tap = parts off the part


1) Start FirstOp.tap

2) Run through program

3) Clean up threads with scotch bright

4) Run PartOff.tap

5) Goto 1

This works perfectly time and time again - however for no reason at all suddenly the G76 in the firstOp.tap program reverts to taper mode for about the first 5 operations and then SUDDENLY goes back to parallel thread mode. When it does this it jams the tool into the workpiece (moves to the proper parallel tool position for that iteration), waits for 2 seconds (ish) and then carries on normally (in parallel mode) as if nothing has happened and finishes the program properly. Without changing a single thing or restarting Mach3 (apart from the broken tool tip) I can carry on running the two programs perfectly again..... until randomly it does the same thing.

I have tried putting the two programs together, but it is the same. It also does it randomly also when doing a "regen" between programs or a regen between end of program and start.

So the program does not crash as such it just gets confused for a very short while, it is almost like it is reading values that are cached somewhere, then the cache gets updated and it resumes on the proper course.

One thing I am doing is swapping from G94 mode to G95 and back

thanks
Rimmel

EDIT******* I have checked the rpm when cutting the thread and it is VERY stable

Hum ...
You start at X9.95, which i assume is an undersize M10.
You have a pitch of 0.75
But you specify an end diameter of 9.00. That's effectively a thread depth of 0.95 mm, for a pitch of 0.75, or an overshoot of 0.2 mm. That's rather a lot. I might go for an overshoot of 0.075, or less.
All the same, it should still work.
I will add that i have done a LOT of theading under .062 with an ESS, and I don't think I have ever had anything like that happen.

That it is RANDOM in occurance ... - um. That is a worry!

I dunno. Have you tried staying with g94 and not changing feed rate modes? I have no idea why that should affect the X movement though (unless you are hitting deep Mach3 bugs).

Cheers
Roger

Hum ...
You start at X9.95, which i assume is an undersize M10.
You have a pitch of 0.75
But you specify an end diameter of 9.00. That's effectively a thread depth of 0.95 mm, for a pitch of 0.75, or an overshoot of 0.2 mm. That's rather a lot. I might go for an overshoot of 0.075, or less.
All the same, it should still work.
I will add that i have done a LOT of theading under .062 with an ESS, and I don't think I have ever had anything like that happen.

That it is RANDOM in occurance ... - um. That is a worry!

I dunno. Have you tried staying with g94 and not changing feed rate modes? I have no idea why that should affect the X movement though (unless you are hitting deep Mach3 bugs).

Cheers
Roger

Thanks for the reply again Roger,

Yes the thread is a very strange one, made to fit an original part. The actual thread is irrelevant though as it does it with any parallel thread if repeated often enough. I have used BSPP, UNC with different pitches/sizes etc etc and all do the same.

I agree it's the random attribute that is foxing me as well. Hence wanting to simply remove any reference to tapered threading in the m1076.m1s

Not actually tried just staying with the G94 mode yet - I guess that is the next move.

thanks again for the replies.
Rimmel

EDIT************ Just found "<TaperRatio>2.</TaperRatio>" in the mach3turn.xml - is that supposed to be set it that value?

Now that I do not know. Sorry.
Can you play with it via an editor? Save current XML, edit happily (or evilly), restore XML.
Cheers
Roger
And off to bed here in Oz.

I *may* have found the problem - will report back later....... testing

After having a lightbulb moment I realised I am using a motion controller for the breakout board - it's a UC100. Now if I remove the UC100 then the problem vanishes (tested for 2 hours and could not replicate the problem - more than 60 .tap interations). Reconnected the UC100 and within 6 interations of the .tap program it errored again.... and again :-( Disconnected and all good again.

The UC100 is on the latest everything (firmware, plugin etc) - I have contacted the manufacturer but no reply as of yet. I do like the UC100, it makes everything really snappy - but at present I cannot use it.

Thanks for all the input and sorry for not realising I had the UC100 installed (it's very small and I am getting older is my only defense).

thanks
Rimmel

Blimey! That IS a new one on me!
Oh well ... onwards. Much pride in solving the problem.
Cheers
Roger