Period setting was EMC error message?
At 01:10 AM 3/20/2000 -0500, Tim wrote:
>
>Ray,
>
>Can you detail how you went about setting your PERIOD parameter??
>
>I have just been setting it lower and lower until EMC will not start any
>more.
>
Yea, but my answer is not any more precise than my servo tune stuff was.
The numbers below are for my pr300 cyrix.
4000 pulses per inch.
10x microstepping
IMHO -----
What happens here is that changing period value changes the demand on rt.
The smaller the number, the more often time will be spent doing the rt pin
setting stuff and the less time will remain for linux to do it's thing.
As you discovered there is a number, smaller than which a computer appears
to lock up. (0.00001) Once it gets freqmod going it's all done. At that
point I backed out of xwindows using <control><alt><backspace> and after a
bit, the main terminal kept showing the repeated message, "Help, no Linux
ever." What came to mind was a sweaty little penguin trying to drag his
ass and my machine up a sand dune.
At the opposite extreme you wind up needing a pulse train that is faster
than the value of period will permit and your max feedrate goes down.
(0.00008) I tried to scope out the underspeed signals but they are a bit
confusing with my old scope.
The best clue for underspeed that I found is that you will hear frequency
changes from your stepper as emc jumps pulse rates at g0 trying to keep up.
When you hear these big jumps you know that you are running the rt process
much to slowly.
But the big question is where do you want to be between. Now I'm really
getting speculative so take the following as being worth about a pinch of
spit. The faster the rt process goes, the smaller will be the steps
between speeds and the smoother EMC will be able to run at commanded speed
because it has more choices between needed pulses that just pulse/nopulse
for the whole next cycle. If the rt process can run its pulse train at
four times what is required for max feed rate then EMC has four choices of
where to switch windings rather than just one. So the motor will run
quieter and closer to required speed.
I guess the nut of it all is that you want to run period as low as possible
without starving the penguin. I started with half way between obvious
motor noise and linux failure (0.00005) and ran EMC using tkemc. Since
mouse motion has a fairly high priority and intensive computation I used it
to burden linux. I just ran the mouse around in circles and watched to see
how often it lagged behind my hand motion.
As I got period down (0.00002) I could see that the tkemc window was
beginning to fill more slowly on startup. At that setting, here were
regular jumps in the position of the mouse pointer as I moved it. So I set
period up a little bit. (0.000025) I still see that it takes a while for
linux to complete it's tasks but the delays are not troublesome.
I was running freqmod yesterday when linux decided to run some scheduled
task. For quite a while there was a load of trafic to and from the hard
drive. These kinds of things don't hurt rt at all but you should allow
some extra time for linux beyond what is required for just the immediate x
windows stuff you have running.
I'm happy with freqmod and the settings I got. This is the first time I've
been satisfied enough to use freqmod rather than steppermod.
Ray
Date Index |
Thread Index |
Back to archive index |
Back to Mailing List Page
Problems or questions? Contact