Gene Heskett wrote: >[snip] > >>Only printing the message once solves that problem, but it means that >>you really don't know how often you are getting a delay. But DON'T >>think just because you get it only once that it is happening only once. >> >>Regards, >> >>John Kasunich >> >> > >Hummm, much food for thought, does it hit the logs or is that skipped too? > > There are two different places where overruns may be displayed.
One of them is available in HAL as the parameter "motion.servo.overruns". You can stick a halmeter on that and see if it increases over time. Note: that parameter may go up by 5 every time there's one overrun - it looks at 5 samples and it's possible that the error will be reported as long as the "bad" sample is in the buffer. There are a couple of other parameters as well, "motion.servo.last-period" (the last servo thread period in CPU clocks) and "motion.servo.last-period-ns" (the last servo thread period in ns - in some cases, this version won't be available). >Doing the test over an ssh -Y link, I see some decent numbers with a worst >case n about 5 minutes of web browsing of 14500ns, 14.5 u-secs. I don't >believe its that good running on its own screen, giving numbers in the >17800ns area IIRC. Still, even 20 u-secs is tolerable. The last time I ran >stepconf, it chose a 78 u-second base period, which did seem rather slow. > > That does sound a bit slow for PWM, but may be fine for step generation. A period of 78 us gives you ~12800 steps/second. If you have 8000 steps/inch, this gives you 96 IPM. >However since the advent of one cycle steps in the stepgen these days, the >text is in bad need of updateing on the wiki page that discusses the >latency-test and how to use it. That is at: > ><http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TweakingSoftwareStepGeneration#Run_a_Latency_Test> > >Since it is assuming 2 cycles per step, the description gets confusing fairly >quickly as I'm not sure what I should throw out to make it sensible in a one >cycle step scenario. > > I wouldn't throw much out, but adding something on calculations for double-step might be a good thing. Remember also that type 1 stepgens may not be the only thing running in the base thread. Any of the phase drive outputs or quadrature can't use (and don't need) doublestep, and then there's PWM to throw in the mix. >Its still running, and showing a base_thread of about 38500ns, and a jitter of >just under 14000ns, so what would be the ideal base_period, ignoring the >startup message that axis's drawing of its gui apparently creates? > > I wouldn't blame it on AXIS until someone shows that it doesn't happen with any other GUIs. :) Actually, it's not AXIS in any case since that's a userspace application - it could be your video drivers if it has something to do with the 3D preview, your disk drivers if it's from loading the startup g-code file, your file system itself (I actually traced a large, periodic RT bump to kjournald on one setup)... It's also possible that the problem is within RTAI - like some kind of condition where some timer setup is done, but before the interrupt is enabled (or directed where we want), more time elapses than expected. That would cause one problem at startup, but isn't indicative of a run-time issue. It's hard to tell what the "ideal" base period is. Stepconf is probably choosing something that will work for whatever scaling and max velocities you've chosen. I don't know if it takes PWM period/resolution into account when choosing the BASE_PERIOD though. Incidentally, what tells you that the generated time is not ideal? - Steve ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
