Rich:
Index debounce will affect the sensitivity of the index signal. IT basically is how many interrupt periods the signal must be present, or not present before a change is actually sensed in that line. SO if set to 2 for example, when the index appears it will be ignored for 2 periods to make sure it isnt noise. Same with when it disappears. Setting debounce too high will make the index go away altogether.
Since the length of the index is dependent on spindle speed, minimum length is variable, but the time must be at least 1 period at a debounce of zero. SO in 25000, thats 40us. The variation of 5RPM or so is really due to the CPU clock base changing, Im still looking into ways to stop that, but a 5RPM over 300RPM would be .6% of actual rpm being in error at maximum, so you may get a pitch variation of .6% , probably not noticable on the thread. For now, I wouldnt worry about rpm fluctuations if they are less than 2% of total. They should be mathmatically insignifigant.
If a person notices a dropoff in RPM at a certain speed, they need usually a lower index debounce OR a wider tag. Index inputs from an encoder are usually pretty short and will limit speed readings at some point as you go higher.
Im seeing quite a few computers that vary CPU clock rate these days, but most seem less than 2% , most less than 1%, so except in long threads this effect should be mimimal. My plan is to continue to work on that as we see what the effect is, so Id like some PP thread results before I jump into further strategies to make things tighter. The changes to MAch3 and the driver over the last few months introduced many errors that we're finally geting rid of, so Id like to see more empiracal results before moving deeper. It loosk like the SS can be considered working fine now, so as results come in on PP threading , we'll discuss the ramifications to the code and the varying CPU clocks happeing in the more modern CPU's.
Thx
Art