John Kasunich wrote: > 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. > I don't think so. I am sure I had it in G64, and the 10,000 vectors describe one orbit around a 2" diameter circle, so the individual vectors are very nearly colinear. <snip> > 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? No, both default and max accel in the TRAJ section is 5.0 user units (Inches) and max_accel in the axis sections is also 5.0
I have posted the program to http://pico-systems.com/codes/contour.ngc just so we can all have a standard to work with. But, I think you have defined the problem quite clearly, and I did not know it worked this way. The blending has a horizon of ONLY one line! Looking at the first 17 blocks : N10 G01 F30 X0.0000 Y1.0000 N40 G01 F30 X0.0006 Y1.0000 N70 G01 F30 X0.0013 Y1.0000 N100 G01 F30 X0.0019 Y1.0000 N130 G01 F30 X0.0025 Y1.0000 N160 G01 F30 X0.0031 Y1.0000 N190 G01 F30 X0.0038 Y1.0000 N220 G01 F30 X0.0044 Y1.0000 N250 G01 F30 X0.0050 Y1.0000 N280 G01 F30 X0.0057 Y1.0000 N310 G01 F30 X0.0063 Y1.0000 N340 G01 F30 X0.0069 Y1.0000 N370 G01 F30 X0.0075 Y1.0000 N400 G01 F30 X0.0082 Y1.0000 N430 G01 F30 X0.0088 Y1.0000 N460 G01 F30 X0.0094 Y1.0000 N490 G01 F30 X0.0101 Y0.9999 we see that the first sixteen vectors are perfectly co-linear, due to roundoff! There is no need to decelerate at all here. And the next 12 are again colinear, and so on for some time. I have no idea how hard it is to do better with this lookahead, I expect it is not easy to handle all possible combinations of moves, with compensations being turned on/off, etc. But, for people doing contouring of surfaces, they often want to skim rapidly across surfaces at 60 IPM with several thousand vectors/inch, therefore, at least 1000 vectors/second is needed. This doesn't require large acceleration, as the vectors comprise a smooth curve. If there is a discontinuity, then the machine has to slow down, of course. Any suggestions are welcome. Jon ------------------------------------------------------------------------- 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
