which version of mach3 do you have by the way? I had a similar problem and i corrected it by changing version..thanks

Hood, I have had various values of Index debounce and I am now back at 0 - nothing makes any difference!

Valmet, I was originally on 062 then I saw another recent thread which suggested that 066 would fix it and also rolling back to 057. None of them appear to make any difference.  058 caused an immediate exit of Mach, 059 would not go past the PP driver install.
Which version are you running?

However I have noted some more curious details also consistent with the change log which mentions 'correcting incorrect parameters being transferred in threading'
My little program which starts at x=0, z=30 and threads to z=0, retracts, g0 to z=0, shows some intersting points when running according to the screen:
Retract which should run at g1 speed appears to be much faster (g1speed set to 40mm/min), the g0 return is running at 400 and not the normal 500 and the return to x=0 g1 speed shows as 31 to 32...
Looking through lasterrors shows that (as I understand it) there are several successful threads cut at 1.5mm pitch, calculated as 350mm/ min, however there are also calculations where the pitch is taken as 50mm and a fail follows. This just happens to be the feedrate associated with the next command. Change that to say 44 and the erroneous pitch follows it.

Happy to hear more suggestions but this is looking like a case of a problem with g32 and the parameters passed to it at some point.

Thoughts anyone...?

Simon

Is the active state of your Index correct? You have it set active low and normally I would expect it active high but suppose that depends what you have connected.
I dont use the parallel port for any machines but I have not seen anyone else reporting the issues you are so if there is a bug it must be something in your setup that is bringing it to the fore, what I have no idea yet.
Will keep looking at your xml and see if I can find something but could you confirm that the index LED is only n when the index pulse is being sent.
Hood

Hood, thanks for keeping up the hunt!

I can confirm that I have a low going pulse - I have a scope looking directly at the cable as I write this
Simon

Would it be possible for you to make a new xml just with the basics and see if it exhibits the same issues? Should really only need axes and index enabled as a test.
Hood

Yes, I will do that tomorrow. My first attempt tonight resulted in lots of problems so I will try with a clear head tomorrow.
Simon

Also attaching my lasterrors and gcode files - I thought I had attached them before but... 

Hood,
Eventually made a new xml and I have just confirmed exactly the same issue with this version...

Thanks for looking,
Simon

Looked through the xml and I dont see any issues so not sure whats going on. I dont think I can realy test out here as I dont think the problem can be seen whilst simulating as if I recall the motor just stalls?
Can you try in Dia mode rather than Rad mode?
Have you tried with a standard lathe screenset? Dont see how it could affect things but worth a try.

Hood

Hunt,

Looked through the xml and I dont see any issues so not sure whats going on

"You are not the only one.....!" 

I tried with the standard screenset - have to say I found it really clunky but it did exactly the same thing.

I also tried with the on board PP just in case it was something to do with the 2 parallel port cards I have installed to operate the mill and lathe - same issue.

I then tried something that seems to help but does not cure the problem - I changed the setting for LookAhead from 20 down to 1 - this causes the errors in the feedrates to go away but the G32 problem still exists.

To recap, since I think there is a danger of my base problem being buried:
when I run a simple 'G32, retract, return Z, return X' code, on some occasions the script _initiates the G32 and then jumps through to the end of the return X, without moving the axes other than a microscopic amount. The DROs however move normally with Z moving from the start at 30 to between 27 and 25, X sometimes moves from the start 0 to 0.3 or so, but not on every occasion.

Points to note are that the G32, retract, return Z, return X are ALL apparently executed - as far as Mach 3 is concerned anyway. It seems to me that Mach suffers a problem with the G32 which causes it to leap through code until it hits a firm stop - an M1 in this case.

Furthermore (when LookAhead is set to 20), the feed rates for the G0 and G1 moves are not those that are set - G0 runs at 400 (I think) and the final G1 to return X to the start is defined at 40 ans actually runs at 33 mm/min. Change the lookahead parameter to 1 and this problem goes away - perhaps linked, perhaps not.

Searching through other threads including another recent one you had commented on, suggests the use of the LastErrors file - this (see my upload earlier) generally shows the threading calculation correctly as a 1.5mm pitch screw, needing 350 mm/min on Z. The failing runs show that the thread pitch to be 40mm, needing 11000 or so mm/min.
One other point is that I see a recent version of Mach (066 I think) has 'incorrect transfer of parameters for threading' as one of the bug fixes - is it possible that this bug is not acttually fixed?

So my own conclusion is that the problem is not a setup issue (as you say, the xml seems ok), but a bug buried in Mach. Maybe it is exacerbated by my setup but I am unable to understand how Mach thinks it has done 4 lines of code successfully when the DROs are not where the program says they should be and when 2 of those 4 lines take a visible finite time to execute.
It is as if Mach has upped the pulse rate to many times higher than it should be.....

So that you can see the problem, I shot this wobbly video on my phone - so sound/picture quality are not good) http://youtu.be/wMDoSYNnRcM but you get the general idea - the only fail that I shot was the first run though.

Almost final question - is there a diagnostic file I can look through to see what Mach *thinks* it has told the PP to do - and what frequency it did it at....or anything else I can look through to pin this problem down?

And finally, if this is a genuine bug, is there somewhere where I can report it as such??