Trevor,
Did you read my reply #96. Your probably correct but i didn't spend a whole lot of time trying to find every single thing. I will waite for a reply from
the writers of the software. What more can i say.

I didn't watch the video yet. I suggest for now just do lighter cuts, reduce your velocity a tad, use backlash compensation. It is the way it is.

RICH

Hi Guys

  there may be two effects here, first, the SS uses its own threading code, totally different from the PP, BUT there was a problem in earlier versions where the PP can do this in G76.. now the SS may have an issue if things slow too much.. dunno havent heard of it.

  So, if using PP, can you confirm its latest version, if using SS ,lt me know. I think Greg may have to look at the SS issue if there is one. But Id like to know if the PP is doing it with G32's..

Thx
Art

Art, Thanks for the reply I am using the latest stable release.020, and the parallel port,  Thanks.

Rich, yes I did read your reply, and your suggestion of lots of lighter cuts is probably the best solution for now.  Thanks

Trevor

Art, yep, same with me, version .020 and parallel port. No missed steps and no backlash. Single index and usually threading at 400rpm. Exactly the same issues as Trevor and others. Fine with light cuts, crazy X with cuts over about 0.05mm deep in steel when the spindle slows noticably.

Nice movie Trevor!

Art,
Thanks for the reply. I am usng the SS wiith the latest plugin. I'll get some info off to Greg and see what he needs,
says, and work with him. Threading on my end has never been better, but, no joy for some others, quite obviously. There are two issues in my mind, namely:
1. Clarity on how the basic threading is "designed" to work ( program reaction to spindle slowdown ).
   ( Not conjecture ie; based on what i found / posted in reply #96 ) and maybe some flavor of anticipated program
    limtations.
2. With one above known, the user or the advice given can better deal with the mechanical system influences
    causing a threading problem in the first place. There will be varing degree's of users lathe systems and this is only
    the beginning as more users start threading.

I will be bold enough to say it again, SOFTWARE  solution to a mechanicaly created one is a patch only and can only do so much. In that light the punny guys got a lot to thank Art for.

RICH

Hi Rich:

  Fair enough, it may explain why Im confused anyway.

 The only difference bwteen G1's and G32's is pretty simple. A g32 triggers a threading mode, in this mode the feed speed is modified for the spindle sync, the move is held until the
buffer has enough data in it, then started at index time.

  Now, while the moption is happening on that move, ( x,z or a mixture depending on the commanded motion ), the spindle speed is monitored. Lets say it slows by 10%, the output stream timing is then slowed by 10% to match, if the speed then goes up, the output speed of the stream goes up. It never goes faster than kernal speed.

 So the command streams are virtually identical, buffered 2 seconds of motion, the only thing that varies is the 25Khz may be slowed to 12Khz ( 50% spindle slowdown sensed.. ) or mayeb 20Khz, ( 20% slowdown of the spindle.), but in the end the only effect coded is a slowdown of the kernal speed. 

  This is all done in the driver, not the application, it monitors the spindel speed, and slows the kernal is required to lower kernal speeds. Its why Im boggled to try to find an
interaction, ( that apparently must exist) between the X and Z motion. Its as if the Z motion is not slowing, but being canceled. I suspect its only possibel if instead of slowing the kernal it actually moves the trajectoy buffer forward skipping steps output, but if that IS true, then the Z MUST go out of position.. Does it?

 We'll track this down to a "Ahh damn.." moment Im sure, but Im justa bit confused abotu where that may be. Can you speak to the Z position, does it go out of
position.. I just cant figure where the heck the extra X motion is coming from if not.. Sounds like Z is goign off, but how the heck can it come back to Z0 if thats true..

Let me know what you see though.. it all helps,

Art

Art,
Fooling with it as i write. I am trying both G32 and M76 and they are behaving the same to me.
This is what i am seeing when dry running:


(Decrement = 0.001 pass 1)
G01 Z-0.1                                   Z IN POSITION WAITING FOR INDEX TO START THREAD
G32 X0.999 Z-0.0997 F0.076923   INDEX / Z ACCEL TO THREAD START POINT
G32 X0.999 Z1 F0.076923            THE THREADING CUT
G01 X1.1 Z1 F0.076923               RETRACT OUT OF THREAD
G00 X1.1 Z-0.1                            RETURN TO THE X OFFSET & Z START
G00 X1                                       X MOVE TO STOCK DIAMETER

                                                 NOW THE SPINDLE SPEED WIILL BE SLOWED DOWN, LETS
                                                JUST SAY 50% ( 100 RPM DOWN TO 50 ).
 
(Min decremant being used)
(Decrement = 0.001 pass 2)
G01 Z-0.1
G32 X0.998 Z-0.0994 F0.076923
G32 X0.998 Z1 F0.076923            SLOWLY- BRING SPINDLE RPM FROM 100 TO 50 AND BACK TO 100
G01 X1.1 Z1 F0.076923                DURING / OVER THE 1" OF THREADING CUTTING
G00 X1.1 Z-0.1
G00 X1
                                                 SOMETHING WRONG HERE. IF SPINDLE WAS SLOWED TO A STOP FOR
                                                 1 SEC ( 1001 ) THEN PROGRAM CONTINUES. IF SPINDLE IS STOPPED FOR 
                                                 3 SEC ( 1001,1002,1003 ) THEN THE THREADING CYCLE STOPS.
                                                 IF JUST SLOWED DOWN AS NOTED ABOVE YOU GET COMMENT BELOW .
                                                 
(Min decremant being used)
(Decrement = 0.001 pass 3)
G01 Z-0.1
G32 X0.997 Z-0.0991 F0.076923   NOW YOU'LL GET A COMBINATION G32 "TAPERED" MOVE FROM THE
G32 X0.997 Z1 F0.076923            PRIOR G00 X1 POSTION AT  SOME  FEED RATE TO .997 ( THERE IS NO CUTTING) 
G01 X1.1 Z1 F0.076923
G00 X1.1 Z-0.1
G00 X1   

                                                 THIS MOVE CYCLE SEEMS BACK TO NORM IF RPM IS STABLE. THREADING WILL
                                                 CONTINUE.             
(Min decremant being used)
(Decrement = 0.001 pass 4)
G01 Z-0.1
G32 X0.996 Z-0.0988 F0.076923
G32 X0.996 Z1 F0.076923
G01 X1.1 Z1 F0.076923
G00 X1.1 Z-0.1
G00 X1

ANYTHING ELSE YOU NEED GIVE A YELL AND I'LL TRY TO DO.

RICH

ART,
but if that IS true, then the Z MUST go out of position.. Does it?

Not according to the DRO's.
And just measured the Z. It dosen't loose position at all ( start and end points). Even when you do a 3 sec complete
stop of the spindle. For a complete stop it just reeturns to the starting Z postion and threadiing cycle doesn't continue.
You will get the error message if spindle is shut off completely that " no spindle feedback seen in G95....etc."
It dosen't seem to lock up MachTurn as i can rewiind the program and just start all over.

RICH

Just for info:

Mach Version: R3.042.020
SS PLUG IN: BETA_V015ogb
Lathe threading Wizard: REV 1.17

RICH

Art, I am glad that you are working on this with us.  I have mentioned before, but I think it may be improtant to answer the question that you posed earlier.  At least in my case no matter ow "wrong" things seem to go the controller never seems to loose track of the actual position of the cutting bit.  That is to say that I can jog the tip of the bit back to the outer corner of the workpiece after a cycle is completed and it will still indicate that it is at 0,0 just like before the cycle began, as a novice this would seem like a pretty simple indication that the software/controller is keeping track of position correctly.  I hape that my way of thinking is correct.

Trevor