Just a bit more from the "Founding Fathers".
Hi Guys:
Having read the various experiences I think I can shed some light on the
matter. I havent decided how to
"fix " the trouble as yet. But I think I have ahandle on whats happening..
to explain , I have to go a bit deeper
than Id normally go. This sort of problem is hard to repair because each
person has their own theories on what is going on,
and often those theories are based on faulty logic of what exactly Mach3 is
doing internally. I think Im seeing a pattern though..
1) How mach3 times the spindle..
When feeding a index input to mach3, mach times how many interrupts it
takes from pulse to pulse. Knowing that the pulse
frequency of your machine is a known constant I use the formula:
RPM = 60 / (IntsPerRotation * (1/ ((double)Engine.PulseCount)));
This gives me the true spindle RPM based on your pulse count from the Diags
screen.. and the number of interrupts taken between spindle pulses. I
probably should have designed it on the actual CPU clocks taken between
Index inputs. The end result of the way its done means that if your diags
page shows a rock solid pulse frequency, as it does for most, the rpm
reading will also be accurate. BUT if the diags page shows a fluctuation on
the pulse count, the RPM will be in error by the % variation of the pulser
frequency.
2) How do we correct the feed during the thread. (assuming 25Khz for numbers
mentioned)
The system plans the motion as always in advance of the thread being cut,
the pulses are all lined up for output. If the number of interrupts between
index pulses stays the same as the premotion samples, then no correction is
made. ( Those that get perfect threads likely have no slowdown so no
correction is applied or have a rock stable pulse count on the diags). If
the index pulse time for the any rotation is found to be longer than the
sampled time ( say 600 interrupts per rotation is normal, and we now have
610 during the cut..) the system know knows that we put out 10 step slots
too much to the steppers or servos. So for the next rotation, we inject 10
waits states evenly though the single rotation so that 10 slot steps are
delayed by 40us each evenly spaced though the next rotation. This means at
the end of the second rotation we now are evenly matched in number of
rotations vs the number of total step slots produced. A step slot is not
usually a step itself. Again this requires a bit of an explanation. Mach 3
works on step time slots more than steps. The buffer hold in it 2 seconds of
motion, evenly divided to 40us slots. Actual motion steps may only occur
every 25th slot or so depenfing on speed. You can think of it as a buffer ot
4096 slots, but if the motor only has to move 100 steps in that time, then
though there are 4096 slots, only every 409.6 slots is a step put out.
Correction of the threading stretches the 4096 slots to be put out a bit
slower by injecting a wait state where the current slot is held until next
interrupt and then output resumes. The motor sees this as a very minor
jitter in time, and the total number of steps is correct. The buffer may
look like this for example before correction...
i = interrupt, S = Step
i,i,i,i,S,i,i,i,i,S,i,i,i,i,S ...ect..
The above is clocked out at interrupt rate. The disance between S's is a
function of acceleration and velocity. During a thread correction.. we'll
add a wait state.. so the buffer may look like this..
i,i,i,i,S,i,i,w,i,i,S,i,i,i,i,S,i,i,i,w,S..etc.
The spacing of the w's, ( wait states), is derived from a bresenham
divider and is very accurate as to how best to slow the precreated stream.
This has proven itself in many area's of mach3, so thats not where the error
must lie. these waits states, unless your traveling at top speed of the
motors have very little effect if any on the motor motion other than to slow
it. For each w state imposed, there may be up top 100 or more i states where
nothign happens anyway, so the induced jitter is less than 1% typically, and
thats a pretty safe spot. At most it creates a sligh "correction" sound in
the motors motion. I havent heard of anyone losing steps as a result, so as
a corrective action for spindle slowdown it does achive its proper end
effect as long as we dont have any of the problems below..
2) So wheres the error:
My thinking is that the error only shows on some machines due to 2
possabilities. First, that user with trouble may not have a solid pulse
number on the diags page. This can be caused by many things, interfering
processes or bad driver operation where it wont lock to speed. PRobably
unnoticable unless your threading as Mach3 tends to smooth the output train
enough that variations cuh as this only become critical in threading runs.
The second possability is a slighly varying index pulse in time.Ive seen
many sensors, ( my own included) that vause RPM variations due to being too
sensitive and varying in time from pulse to pulse. Adjusting senstivity
solved my own issue with that.
Bottom line.. the best performace will be if the diags shows a rock solid
pulse frequency, and the RPM shows as stable when your just running a
spindle and not threading.
I have to give some though as to if perhaps using the CPU clock rather
than counting interrupts woudl solve most of this, the CPU clock I can read
in nanoseconds time base, so if the pulseing engine is a bit erratic in
timing , then the cpu clock woudl self correct for that.. in the meantime,
check the pulse frequency on the diags..is it stable? if not, try shutting
off everythign in the startup of msconfig, even if your unaffected in other
situations. Threading is very suceptable to variations, and since my
computers tend to be rock solid in this, Im suspecting its why the variation
inthreadin is hard for me to track down..
Im really thinking that I need to option the "correction" algorithm so you
can turn it off to see if that stops the threads from destroying
themselves.. Ill talk to Brian about updating the application code to give
you a checkbox to turn off correction while I
think about a driver update to switch to actual nanosecond time base instead
of interrupt count time base. Being able to turn off correction, but leave
triggerign alone will IMO, probably fix up almost all problematic threads to
only show the effect of a
slowing spindle. Most have no slowing spindle during a thread, so the
floating pulse frequency causes the corection to hurt rather than help the
final product..
Let me know how your experience match the above explanation or not.. :-)
Thanks,
Art