Jon Elson wrote: > At the request of a potential customer, I did some performance > tests with EMC2. I created a program with 10000 blocks like > > N123456 G01 F30 X1.0000 Y0.0000 > > with the coordinates working around a 2" diameter circle. > Each chord is roughly 0.0006" long. I ran it with the > feedrate at 30 and 60 IPM, no difference, so it wasn't > acceleration-related. I got 4 minutes and 17 seconds both > times. That works out to 38.91 blocks/second or 2335 > blocks/minute. This is on a 600 MHz Pentium III running > my universal PWM controller at a servo update rate of > 1 KHz. > > Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. > > Jon >
Your test is not measuring interpter speed, or anything else that is likely to be improved by a faster PC. I am almost certain you are seeing acceleration limited behavior, but without knowing the accel limits of your config I can't do the math to be sure. First a quick look at other "bottlenecks": There is no way the interpreter is only doing 39 lines per second. I would expect the interpreter to be able to handle tens of thousands of lines per second on a fast PC. I can't think of a meaningful test of interpreter speed at the moment, but for all practical purposes it is fast enough that we don't really care much. The next bottleneck is passing commands to the motion controller (realtime code). EMC's motion controller has basically two parts that both run once per servo cycle. One is the command handler (mostly in command.c) and the other is the control code (control.c and lots of files linked to it). Each time it runs the command handler takes precisely one command from the user space code and either executes it or queues it (depending on the type of command). That means it with the default servo rate of 1KHz you can at best send 1000 commands per second to the motion controller. In practice the limit will be a bit lower, since the user space code sleeps once it sees that the motion controller hasn't accepted a previous command. The controller will accept the command after 1mS, but if the Linux (non-real-time) doesn't wake up the interpreter for 3mS, the max throughput drops to 333 commands per second. Once the command handler gets a motion command it goes into a buffer that holds 200 moves. When you start a program, the interpreter and command handler quickly get 200 moves ahead of the motion (unless you have tiny moves like your test program). The 200 move buffer is what lets us run the interpreter in user space. It's also the reason that the active g-code display doesn't track the program. Neither of those things explains your results. You said the times were the same with feeds of 30 and 60 ipm, but that does NOT mean the timing is not acceleration related. Did you try with two different accel values? Your segments are 0.0006" long, and you are requesting 60 ipm or 1 inch per second. The only way you will reach the requested speed is if your move is a trapezoid - with accel, cruise, and decel phases. The only way you get a cruise phase is if the move is long enough to let you reach cruise speed. First lets look at the case where you are in exact stop mode. Every move will have to accel and decel. If a move is 0.0006 long, the decel part only gets 0.0003 inches. The distance covered during the accel or decel phase depends on the target speed and the acceleration. The math looks like this: Speed at start of ramp: V0 Speed at end of ramp: V1 Average speed during ramp: Vavg = (V0+V1)/2 Time to reach final speed: T = abs(V1-V0) / A (A is accel in in/sec^2) Distance traveled during ramp: D = Vavg * T Substitute for T D = Vavg * abs(V1-V0) / A Substitute for Vavg D = (V0+V1)/2 * abs(V1-V0)/A Simplify D = (V0+V1)*abs(V1-V0)/(2*A) Solve for A A = (V0+V1)*abs(V1-V0)/(2*D) We are interested in the case where you are going from some speed V0 to a complete stop. So V1 is 0, and the you can simplify some more: Decel rate for full stop A = (V0*V0)/(2*D) If you are making moves that are only 0.0006" long, you have 0.0003" to accelerate and 0.0003" to decelerate. So, V0 = 1.0 ips and D = 0.0003. If we plug those into the last equation we get A = 1666.7 inches per second squared. That is a LOT of acceleration - over 4G. Most machines have accel limits well under 1G. That means most machines will not be able to reach the requested 60 ipm during a 0.0006" long move. So, exactly how fast _can_ the machine go during a 0.0006" move? That depends on the acceleration that the machine can deliver. Let's say the machine can do 50 ips^2. (That is still pretty good - it means you can go from stopped to a 120 ipm rapid in 1/25th of a second.) The best we can do is accelerate full blast for the first half of the move, then decel at the limit for the second half. To calculate the maximum speed based we re-arrange the equation above, solving for V0: V0 = sqrt(2*D*A) D is half the total move, or 0.0003". A is 50 ips^2. So V0 works out to 0.2449 ips, or 14.7 ipm. A machine with an accel limit of 50 ips^2 simply cannot physically go faster than 14.7 ipm on a 0.0006" long move, and still be able to stop at the end. In exact stop mode, the average speed would be only half that value, since each move starts at zero, accelerates to 14.7 ipm, then decelerates to zero again. Attempting to run this program in exact stop mode would result in an average speed of 7.35 inches per minute, and a horrible amount of vibration as the machine slams between max accel and max decel. What about when blending is turned on? EMC2 has one-segment lookahead. It looks at the next move, and blends the two together if possible. The blending is fundamentally quite simple (although dealing with all the possible cases is not.) EMC2 calculates the accel, cruise (if any) and decel numbers for each move as if it was in exact stop mode. But then it starts the accel phase of the next move as soon as the decel phase of the current move begins, and adds them together. Move 1 is slowing down, move 2 is speeding up, and if the two are at a mild angle to each other they ramps cancel out leaving a very smooth movement. If the two moves represent a sharp turn, the overlap between their accel and decel periods tends to round off the corner. EMC2 has special code to detect that this would happen, and if the rounding is worse than the specified tolerance EMC2 slows it down some more. Since EMC2 calculates each segment as if it were doing exact stop, blending doesn't increase the maximum speed. It does increase the average speed, because the tool isn't constantly slowing down and speeding up. And it makes the movement _much_ smoother. In the case above, where the accel limit is 50, blending would result in an average speed of 14.7 inches per minute. Jon's program made a 2.00" diameter circle, with a circumference of 6.28", and it took 4 minutes 17 seconds. That works out to an average speed of 1.46 ipm. I worked the equations backwards and got an accel value of almost exactly 1.0 inches per second squared. Jon: Is the accel limit on your test config 1.0 inches per second squared? Regards, John Kasunich ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
