I made this program http://pastebin.ca/993663 (same thing I think as Jon
made)
I ran it on the live cd (hardy is all I have handy at the moment) on a
dual core 2.2ghz. (not the greatest latency - around 20us. Anyway..
With the default stepper_inch.ini - acceleration set to 20In/s/s the
program takes 1min40sec. (side not - the velocity on the axis screen
reads 0) I upped the traj and axis acceleration (x and y) to 100In/s/s
and the program took 1min40sec.. :) as much as I could tell with a
second hand on the clock. So that calculates out to about 3.77ipm.
Now - If I add G64P.0005 - the program and leave the acceleration to
20In/s/s it cruises along at 30ipm.. :) cool. Takes about 13 seconds.
sam
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.
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
-------------------------------------------------------------------------
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
