Hi Guys,
just some thoughts.

i don't think a stalling stepper is the problem since the G Code is stopping at that moment.

As I posted before I did some test ( .062 ) everything is well here.

Some things I found while testing.

The pulse must com in clean and stable. That means the Speed should be as stiff as possible.

The feedrate during threading should be not more then 75% of rapid traverse.

The G0 feedrate will not reach 100% after the G32 command unless there is at least a G4P0 command after G32
this does not affect a successful thread.

Feed Override must be 100% ( feed override is not disabled)

I think the index pulse is not coming in clean or there is a hardware conflict or whatever affect the pulse.

just a thought and may be wrong.

BTW is it possible to stop Mach writing to the LastErrors.txt file at least during threading ?


Regards
Alex

Art, Alex,

Let me try and deal with each point in turn since this problem has evolved since my original plea for help:

• Alex is right, the ''chirp' is not visible on the lathe - I have had a DTI on both axes and the error consistently manifests itself as a stop during or after the G32 with the Z axis usually showing about 27 (Z runs from 30 to zero) and there is no movement of either axis. If you have the chance, you can see it happen on one of the first runs on each of the YouTube vids I posted
• double G32 - this is the output from the Simple Threading Wizard (v1.17 I think) after I set the test=true flag. That was what initially confused me and my poor lathe was valiantly trying to do what it said. I suggest this is simply a separate issue that presumably needs addressing as well.
• Use actual spindle speed checked - Hood and others have validated my xml
• Alex's comments about needing a G4P0 explains why I see the G0 feedrate less than the expected, thanks - and I guess that is also why the G1 is also running slowly
• Feedrate <75% of max feedrate is fine, albeit close - but I have seen the problem on finer threads as well when I tried to cut a 0.8mm pitchl
• Unclean index pulse - my thoughts as well, however it looks very clean and sharp on my digital storage scope as viewed at the parallel port connector on the PC
• hardware conflict - also had similar thoughts so I swapped the external PCI card PP over to the onboard one in case it was related to that but no changes occurred
• Mach seems to write to LastErrors all of the time but with less information than if the debug flag is set

I will return to PC and index pulse debug I think - I did test using the Driver Test which seemed ok, is there anything else that I can apply or am I now deep into the workings of my PC and the world of XP?

Regards,
Simon

PS how do you stop bullets taking bold italic fonts??

Hard for me to believe its the index pulse, your time of int seems good on the rotation sensing.. BUT, the program has changed a lot since I was in there, Im still using .028 as my version, but it has changes Ive made for myself over time so Im not great anymore at figuring out whats going
on in generalized sense.. My emco hasnt done threading since I wrote the routines..

Art

Hi Art,

The code generated from the Simple Threading Wizard ( M1076 configured for G32 output ) always had double G32's as shown in the format below.
Use it whenever I do threading, never questioned the double G32's, but then, never had a problem when using it.

(Decrement = 0.005 pass 1)
G01 Z0
G32 X0.245 Z-0.0014 F0.025
G32 X0.245 Z-0.9969 F0.025
G01 X6.25 Z-1 F0.025
G00 X6.25 Z0
G00 X0.25

RICH

Rich:

  In theory it can work in a limitded instance, but the second one is redundant, once triggered the motion will simply continue
unabated I think. It will have no real effect, but has dangers if one were to string a bunch together as the triggering wont be as one
would expect. I never understood why the G32 advance was written that way, but then as I said, its been too long, like trying to
second judge a project long put away.

Art

Hi all,
Simon,
please try the following.
note all your settings in mach on a sheet of paper ( or make a screenshot )
delete the old XML's ( or move it to an other place )
reinstall Mach3 ( be sure to do it as recommended )
reboot PC
important: DO NOT load an old profile ( XML)!
There will be a new fresh Turn Profile
DO NOT load an other screenset as the standart  !
type in your settings and test the result.

It looks to me that your XML corrupted the system ( Mach3)
at least it did mine. grrrr        



Alex

All,

Now that I have deeply investigated my problem and have found a solution, I want to share it with you all in the hope that it may help others in a similar situation as well as as a sort of 'thank you' to everyone who read and contributed to the apparently never ending saga.

Briefly, the problem was that I was unable to cut threads reliably without the lathe deciding at some point to not start a particular pass of the thread. All electronics looked fine and the problem was intermittent. I tried many tests and solutions proposed here as well as my own, none being successful

Finally I resurrected the ancient PC that came with the lathe complete with the original Emco software and installed Mach on top of the French Windows 2000 OS. This proceeded to work perfectly...I have since installed Win XP and reinstalled both Mach3 and the updated screens from Calypso and it continues to work perfectly. Meanwhile the PC that I was using for both the lathe and my mill (not simultaneously!) continues to work perfectly too...
Thus the conclusion that I draw is that that particular PC has some bizarre timing issue that causes problems on time critical items like screwcutting but allows perfect function on the less critical mill. Who knows what, I no longer care!

The moral of the story and the 5 pages of forum space is that if you see an odd problem, try another PC.

Thanks to you all

Simon

Glad you have something that works even though we have no definitive answer as to the actual cause in your case.
I can live with your case closed.  

RICH

Rich,
I really wish I could offer a detailed breakdown of the problem for everyone's benefit but I have lost the enthusiasm for debugging elderly Win XP PCs - if I ever had any!
Hopefully no-one else will suffer similar problems, or if they do, they will consider trying another PC as part of their investigation.

Thanks again to you and the others for your help and efforts.
Simon