Hi Matt, Are you running the quickstep driver under the real-time kernel? As I understand it, the normal performance measurement programs are not aware of the real-time kernel usage, and may erroneously report it. Paul_C can you clarify? -- Regards, Doug Goff [email protected] www.woodntractors.com Scale Tractors In Wood "The man who sets out to carry a cat by its tail learns something that will always be useful and which never will grow dim or doubtful." - Mark Twain
Hi Doug, Yes, it's still all real-time. To measure CPU usage, I just ran bogomips in user space. This tells me how much CPU is left over after all the higher priority tasks take their cut. If M is the score when the system is unloaded, or reported during boot, and m is the score when EMC is up and doing a rapid move, I know that the fraction of CPU consumed by the real-time tasks is <= (M-m)/M. Uncertainty remains about just how fast you can go, however, because quickstep's critical work isn't quite evenly distributed across PERIODs. I don't think it's too far off, though. On a slower machine, I guess that it's probably safe to decrease PERIOD until the real-time work eats up half the CPU. A really fast machine may hit some limit in the capabilities of the interrupt hardware first. -- Matt
Hi Matt On Monday 13 February 2006 04:47, Matt Timmermans wrote:
Uncertainty remains about just how fast you can go, however, because quickstep's critical work isn't quite evenly distributed across PERIODs. I don't think it's too far off
Quickly threw an emc-modules package together containing your driver and another tweak to the trajectory planner - This is already up on http://bdi4emc.ourproject.org/debian and should hit the other mirrors sometime in the early hours.. Initial tests with the default module parameters are impressive. Overall performance of the test box shows a marked improvement over running freqmod, and the speeds appear to be much higher. I need to make time to hook up a mill and get the scope on the parallel port in order to gather some real world data... Let the testing begin. Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
Paul>
Quickly threw an emc-modules package together containing your driver and another tweak to the trajectory planner - This is already up on http://bdi4emc.ourproject.org/debian and should hit the other mirrors sometime in the early hours. [...]
That was fast -- I'm glad to see it up so soon! A note on setting PERIOD for the quickstep driver: My 3.2 GHz P4 (that doesn't actually run any machines) likes PERIOD=7us. The P266 laptop that runs my Sherline likes PERIOD=15us. The laptop can actually run with PERIOD=10us, albeit slowly, so that's probably the best bet for the 1.x GHz class machines that are often used with EMC and steppers. 15us is probably a good .ini default, since it works on low-end machines, and it is really plenty fast. I spent a bit of time this morning watching the Sherline zip around at 48 ipm using that setting, and those little handwheels spinning around at 960 RPM convince me that you really wouldn't want to drive a stepper system any faster. I got worried about damaging the thing, throttled it back to 24 ipm, and tightened up the gibs as a penance. With the module package available, anyone who uses freqmod in STEP/DIR mode with <= 4 axes and wants to try it should be able to do so like this: - install the new emc modules package; - make a copy of your current .ini file; - edit the new copy and change EMCMOT=freqmod to EMCMOT=quickstep; - change the PERIOD setting to 0.000015 or 0.000010 if you're brave; - change the MAX_VELOCITY settings in TRAJ and all the AXIS sections to whatever you want your rapid speeds to be; - If you set your rapids fast, make sure the acceleration limits are realistic, or you could miss every step in a rapid move. All of your other settings should carry over. The PID settings aren't used, so it doesn't matter what they're set to, and you don't have to do any of that tuning stuff. To run, in /usr/local/emc, do ./generic.run -ini new_ini_file.ini. Caveat: EMC currently ignores acceleration limits while doing backlash compensation, and it does it at the axis rapid speed. That's fine for servos, but not so nice for steppers, so if you have backlash compensation set, you may miss steps there if your rapid speeds are too high. I'll put a strict enforcement of the acceleration limits into the quickstep driver sometime soon. -- Matt
Hi Matt On Thursday 16 February 2006 04:05, Matt Timmermans wrote:
A note on setting PERIOD for the quickstep driver: My 3.2 GHz P4 (that doesn't actually run any machines) likes PERIOD=7us. The P266 laptop that runs my Sherline likes PERIOD=15us. The laptop can actually run with PERIOD=10us, albeit slowly, so that's probably the best bet for the 1.x GHz class machines that are often used with EMC and steppers.
With the Celeron 433 that I use for testing, using the mini GUI, I tried 5uSec.. Bogomips reported 66 (426 without EMC running), and KDE was very sluggish. Jogging the A axis could be best described as erratic - The parallel port is a vintage ISA card, which as we know, takes a significant period to write data to, so 5uSec is pushing the limits somewhat. Using a more realistic period of 7.5uSec (146 Bogomips), the computer is a lot more responsive, and rapids can quite easily hit insane levels (for a Sherline). Normally with freqmod, I would have gone for a conservative 20uSec and set the max velocities fairly low.. Going to have to dig out the scope and do some serious back to back testing with a few other computers, perhaps adding some additional data to /proc/emc to characterise the loop times a bit better. In the past, I have used freqmod with periods of less than 10uSec, but found jitter to be problematic... I have a few thoughts on tying quickstep in without duplicating the module init/cleanup routines to bounce of you at a later date. Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
participants (3)
-
Doug Goff -
Matt Timmermans -
Paul