Rich:
Now thats interesting data!!!. In the report, you can ignore all the ones with vel:40.5 , thats just the program loading up.. Your passes are obvious
when it shows the Pass number due to your comments in the code.
SO we get..
Fri - 01:53:03 ---Decrement = 0.005 pass 14
Fri - 01:53:05 --- Threading pass: Vel: 0.3367
Fri - 01:53:05 --- Threading pass: Vel: 0.3367
Fri - 01:53:06 --- Threading pass: Vel: 0.3375
Fri - 01:53:10 --- Threading pass: Vel: 0.3358
Thatys one of your "bad" passes. Some of the other bad passes show only the variation of .3367 to .3375.
So lets crunch that a bit..
As feedrates go, that per second, so the bad run could be considered..
Fri - 01:53:03 ---Decrement = 0.005 pass 14
Fri - 01:53:05 --- Threading pass: Vel: 0.3367 thats feedrate 20.202
Fri - 01:53:05 --- Threading pass: Vel: 0.3367 feedrate 20.202
Fri - 01:53:06 --- Threading pass: Vel: 0.3375 feedrate 20.25
Fri - 01:53:10 --- Threading pass: Vel: 0.3358 feedrate 20.148
Now thats the highest variation I see in the reports. So we need to divide by the
spindle speed to get the pitch you requested. So 20.202 / 404 = .050000 ( middle case )
and 20.25 / 404 = .050123 ( higest pitch called) , and finally 20.148 / 404 = .04987 ( lowest pitch called for.)
So your numbers seem to indicate that when we consider the spindle speed, and the feedrate calcuated from it,
the pitch varies from a low of .04987 to a high of .050123 or a variance of .000253 in terms of pitch.
Since a 1/4 20 thread is .05000 pitch , we have a pretty tight planning being done according to these numbers.
Seems to be less than 0.5% variation.. all threads , even the bad ones should have been good according to these numbers.
At most you should have seen less than .000253 difference from thread to thread. Tells me that the RPM is NOT the problem,
nor is the feedrate calculated for the pass.
I need to think about this for a bit to see what to test next. This shows an almost perfect reading of RPM, as well as
perfect control of feedrate to match the read RPM. That variance must have meant the feedrate was solid ... hmm..lets calc that
while we're crunching. You planned for .050000 as a feedrate, it varies only due to rpm readings, so we can multiply it out
to see what rpm you were reading on each of the three pass speeds we are getting. Code assumed 404RPM, and what we got was..
perfect reading of 404 would give you .33666666 as a velocity. ( 20.2 / 404 = .05 pitch @ 20.2 / 60 = .336666666....)
.3358 * 60 = 20.148 = 405.04RPM
.3367 * 60 = 20.202 = 404.04RPM
.3375 * 60 = 20.205 = 403.0 RPM
So at most 2RPM was floating. How accurate that was can be measured as a function of the end pitch results, which seem to
be very close, thus the measured RPM must be very close indeed.
So all in all, Id have to say what we're seeing is just and proper. Youve disproved any problem caused by RPM measurement,
or trajectory speed calculations. This pretty much verifies all of Mach3's code with the exception of the driver itself in terms of
created the crazy result moves that have occured with the very weird high advancing leads on some passes.
This may explain why the SS seems to be found to be very tight, it has no PP driver, and results seem good, so it
all makes great sense when you think about it. While its true the SS and Mach3 both may have a sligth advance or a slight
decrease in pitch from nominal, thatr I think may be the result of the planners conception of time, asnd probably something
that can be corrected.
SO its my feeling we're left with "What is it that causes the crazy moves intermittantly?" This is what Id like
to focus on I think. And its where we have to go to see what it may be thats causing the trouble. And this means its
going to get complex from here on. :-) ( As if its been easy so far..)
If we can eliminate the crazy leads, then we'll only be left with making the pitch itself as close as we can get it.
We only have the reports of what the RPM was at the start of each thread.. this doesnt tell us if indeed the RPM slowed
signifigantly DURING any thread. We have the corrrection turned off at this point, so if the spindle slowed during any pass,
the pitch would give us a "crazy" move indication as the pitch would be way off. It would lead signifigantly for that pass.
Although it may start OK, as it slows the thread pitch would advance as the feedrate would not at the moment slow down to
match the spindle.
Im thinking it best to perhaps monitor the spindle rpm during the thread. This woudl create too much debug traffic,
so perhaps I can code up somethign that records the upper and lower limits of RPM seen during each pass. that may help
us better identify the culprit of the crazy passes. Im betting the warmer the spindle the less often this bug hits us,
as I think it may be related to the VFD's correction mechanisms as it slows down or speeds up the spindle to match its own
window of tolerance on the spindle rpm. (But I could be wrong..).
Ill dwell on this for a day or two and coime up with something to feed us more data, so far youve disproved almost
any application side reason for varying pitches, as everything is pretty much as close as I think anythign could be.
Comment on anythign you think I may be missing or screwing up here..
Thx
art