Threading 'memory' of spindle locaton

[SamMarrocco]

I'm curious at what point the KFlop "stops remembering" the spindle position when threading. If changing the speed of the spindle during G32 varies the speed of the cutter move, and stopping the spindle stops the cutter move, what exactly can cause it to stop being in sync? Is it once the interpreter has stopped or a reset has occurred?

[TomKerekes]

Hi Sam,

After a G32 is executed Spindle sync remains in effect until a G0 Rapid, or G4 Dwell, or anything that causes the Coordinated Motion Buffer to flush such as an Interpreter Halt or something like an S or M Code that is not an embedded IO command. (ie Execute C Program).

In the code see CheckIfThreadingInProgress(void) which calls FlushSegments() which calls DownloadInit() where CM->m_ThreadingMode is set false.

[SamMarrocco]

Thanks, Tom.
I figured an interpreter halt might be the culprit (my threads seemed to be drifting after 50 passes or so) but I suspect I might have a stray S Code in there causing the problem. I'll check into that.

[TomKerekes]

Hi Sam,

Well normally there is a G0 between passes so there is a re-sync for each pass. And this is normally required. If each "loop" for a pass remains continuously in sync then unless the loop path length isn't exactly a multiple of the thread pitch then the threading will be off. Each "fresh" G32 should sync by waiting for the spindle to be at 0 degrees and then begin the motion. For this to work the spindle encoder must work perfectly such that 0 degrees is always at the same place. If there is any spindle encoder noise, or if the correct counts-per-rev for the spindle isn't specified exactly then the 0 degree position will drift.

Does this make sense?

[SamMarrocco]

Yes, that all makes sense and it helpful, thanks.

Full disclosure, I have been doing this (overly simplified)

Start
S800
G32
G0 clear the threads
G0 back to startpoint
Repeat from Start

So if I understand correctly, you saying that the G0 rapids at the end of this code will cause the CMB to flush, causing the sync to be lost, but it *still* remembers the spindle's index of 0 degrees, so the next G32 call is still synchronous with the previous G32 call from the last time it was called? If so, then that shouldn't be the cause of my issue.

The correct counts per rev for the spindle is drifting a bit from the specified S value, maybe by 10 percent or so as the cutting slows my spindle.

As for Spindle encoder noise, I may have to break out my scope and look into that.

[TomKerekes]

Hi Sam,

The correct counts per rev for the spindle is drifting a bit from the specified S value, maybe by 10 percent or so as the cutting slows my spindle.

Well no, the speed of the spindle doesn't change the counts per rev.

As for Spindle encoder noise, I may have to break out my scope and look into that.

I would do a test to check for lost/gained counts in the following manner:

#1 with the Spindle off Zero the encoder and mark the Spindle angle physically with a marker
#2 run the Spindle for a while at various speeds until the Encoder reads a huge number
#3 turn off the spindle and manually move the Spindle to the mark
#4 divide the Encoder Position by your counts-per-rev
#5 check that the result is very close to an integer ie 1234567.001

[SamMarrocco]

That would be simpler. Is there a dotnet call for reading/setting the spindle encoder location/count?

[TomKerekes]

Yes KM_Axis.GetActualPosition and KM_Axis.SetCurrentPosition.

But why not just use KMotion.exe?

[SamMarrocco]

I was planning to add that vb code into my own CNC app so it would be visible for potential troubleshooting in the future.