It was basically the way Art was calculating things and I think spindles speeding up slighly threw things, most common with VFD controlled spindles. The latest driver can now account for spindle speed up, think 125%, so that should be more than adequate for most.

The problem has always been when a few reported threading issues Art would work with them and a fix would be found, problem was because of the small user base it was not widely tested so it was thought it was cured but in reality it had just been tuned to the testers machines.


Hood

Rich,

Attached  XML.

Jorge

Hood,
Ok good to know since i haven't been following the Yahoo group and didn't notice anything here. Back when ever, you needed to set the speed manualy even if you had a VFD.
Thanks,
RICH

Jorge,
First can you set the spindle speed manualy?
Tick the box for Spindle Speed Averaging.
You never replied back telling me what kind of index you had. Is it a single pulse per rev or multi? You only want to have a single index.
How close is the PPS during the driver test to the selected khz setting?

Mach looks at the pulse and determines the true RPM, the more stable the better. Lets assume that it is exactly the same for now.
If the DRO is fluctuating  by say  one rpm or so that should be ok.
So if the rpm is stable and the same, then when the index is sensed, the G95 mode is allowed / the G32 coded line is implmented . Mach provides for a Z axis move such that the controlled cutter point will hit the same exact start point of the thread. That is true for your posted code as you have the Z sitting at the same location waiting for the index and doing the same move.

So do another scribe test with the rpm set manualy and see what happens.
RICH


RICH


 

Hi Rich,

I think I can set the spindle speed manually.  By this I guess you mean directly from the VFD without commanding it from Mach.  I will try that.

Ticked Spindle Speed Averaging, same behaviour.

Ticked Spindle speed feedback.  Spindle variation less than 2 RPM, but no improvement in threading.

I have single pulse.  It is the index pulse from a heindenhain encoder, that goes through a break out board (otherwise it would be too fast for mach).

Attached PPS test result

Installed latest Dev version and behaves the same.

Clue:  Tried a 10 sec delay (G4) before each G32 and the offset between threads diminshed. 

Will try manual control of the spindle and see what happens.

Jorge

Sorry, I got the wrong driver test photo in my last post.

BTW I am using Windows 7

Tried a 10 sec delay (G4) before each G32 and the offset between threads diminshed.

Hmm ........ that would be similar to using a high index debounce ( how manny times the index signal must be seen before accepted ) in configuration.
Some work with a setting of 0, I use 10, and think yours was set at 100.

By manualy setting the rpm ......and should the scribing turn out good.... then you eliminate the index as a possibility and the problem lies in control / reading of the VFD rpm. By scribing you are eliminating any cutting forces which could alter the rpm. Just trying to pinpoint the problem.

BTW, XP Pro here.....see no reason for W7........guess i am getting old and cheap!  
RICH

Instead of the encoder tried a slotted disk with a hall effect sensor.  Problem got solved at least to the naked eye.  Problem could have been related to the signal stretching circuitry of the BB board or to the encoder itself, or any other unknown cause, not sure.

Tried V42.033 and worked fine.  Then installed V43.022 (latest lockdown) and unusual jerking in the Z axis started (just in threading movement). Installed back V42.033 and jerking continued.  Installed latest dev. version and all went back to normal.  Cannot explain what happened...........

Link to how i installed a Halls sensor.
http://www.machsupport.com/forum/index.php/topic,12484.msg82818.html#msg82818

RICH

Hi, can Mach3 make threading conical? If i define G76 Xend Zend conical could make this but i now no have implemented my turn and can`t probe this.

regard
Renato