On Wednesday 19 March 2008, Stephen Wille Padnos wrote: >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.
It, from here, just went through the axis logo, several times and is still at 0 for motion.servo.overruns. This is with a base_thread setting at 38 u-secs. The machine will run at 25 but pretty laggy. I was running it at 30 before the new single step stepgen came out >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). > It is, and from here, motion.servo.last.period is a 7 digit number left of the decimal, dancing but usually in the 137xxxx. range, motion.servo.last.period.ns also dances some, in the 97xxxx. range NDI if these are good or bad. Sounds large though.. >>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. 32000 x&y, and 34xxx on z. and I just found the ini file is wrong, I must have entered the stepdown pulley teeth in the wrong order. Fixed that from a -85xx.xxxxx to -34285.7142857. :( 20 tpi screws direct drive on x&y, 10 tpi, but a 14/30 stepdown on z. A is direct to the worm, 10 degrees per 1600 step motor rev so one turn of the table is 36 turns=57600 microsteps= 1 full turn. Scale=160 in the .ini file so I assume thats a per degree setting. >>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. Give the list a notice when that has been done please. Which could be important for some, here it is only spindle control with updates at servo_thread rate, which is much faster than the 100 hz pwm rate. With the filter option set at 1 second on the PMDX-106, the response is slow & makes the servo sound soft, but I don't think it will be when cutting. I didn't build my ammeter into the new circuit yet, ran out of panel room for it. >>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. :) Since axis came out, I haven't used anything else but, I'm NOT pointing the finger at axis, just gui's in general. >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)... Interesting, how the heck would one go about instrumenting to detect that? >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. That has been my impression particularly since the audible step rates when its marching along at a goodly speed of 20 ipm, are a pretty pure tone, no raggedness that these ears can hear. Eventually the tone drops into the carhart notch in my hearing so it gets hard to hear. :( I'd worn out several rifle barrels before I got any shooting earmuffs. Now I carry 3 extras in the range box in case others don't have them. >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? The error. It pops up at about the time its clearing emc.gif from the screen, so just for grins I set that display to 2 seconds to see if it makes any diff the next time I start it from its own keyboard. Get that litle detail out of the way just for grins. I'll make some noise if it helps when launching it from its own screen. But I've been blaming the video driver so far, and yet it seems to run fairly well using the nv driver, which is visibly slower at screen updates, causing obvious artifacts in the tracing accuracy while going around corners that the nvidia driver traces just fine. So I use it, installed from the .run package. NVIDIA-169.09 ATM. Comment about glxgears though. I think when ssh'd into it, that is testing the drivers on this machine based on the fact that if I run glxinfo, I get data from this machine, not that one. And glxgears, running that way, doesn't make its every 5 second reports, or update the screen at all well, so under those conditions its not a real load nor usefull as a load. I also have laying about, an ATI card based on the r-280 chipset (a 9200 SE) that I could install in that box, but the radion drivers when I had it in this box weren't up to handling tvtime without some frame losses. ATI, now AMD, will have to release good drivers before that brand will go across the scanner at circuit city again and into a bag for me. Lots of publicity is all I see so far. That dog & pony show has cost me $everal hundred over the last decade. Thanks Steve. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The meta-Turing test counts a thing as intelligent if it seeks to devise and apply Turing tests to objects of its own creation. -- Lew Mammel, Jr. ------------------------------------------------------------------------- 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
