Trajectory planners used with all LinuxCNC releases have
employed trapezoidal velocity profiles (e.g. fixed accels,
no jerk limiting). With trapezoidal planning used for both
rapids and feed moves the only individual segment motion
types are:
1) velocity ramp segment:
v = a * t
x = 0.5 * a * t^2
time for a segment: t = sqrt(2 * x /a)
2) fixed velocity segment:
x = v * t
time for a segment: t = x / v
To speed up by a factor K (with resulting elapsed times of
t/K) for both segment types, it is necessary to set:
a' = K^2 * a
v' = K * v
For testing, it is convenient to use a sim configuration
that just connects motion cmd pins to motion fb pins.
Gcode programs used for testing prediction linearity
should have no:
pauses
waits for spindle speed
tool changes
probes
or any other commands which take fixed or variable amounts
of time unrelated to motion planning.
I used a script to set inihal pins for velocity and
acceleration and to measure program run times. The script
accepts a multiplier (K) and:
1) increases all inihal velocity pin settings by K
2) increases all inihal acceleration pin settings by K^2.
3) uses halui pins to increase the feed override by K
(For the axis gui, the setting [DISPLAY]MAX_FEED_OVERRIDE
should be set to a large value so that halui feed-override
settings are not limited.)
I tested using a gcode program based on nc_files/tort.ngc
modified to:
1) eliminate the single pause (m0) line
2) put the main code in a subroutine and run multiple
iterations to get a total program runtime of about
90 minutes (at normal speed/accel settings).
Test results:
K (multiplier)= 1 measured time = 5406 secs (baseline)
K (multiplier)= 2 measured time = 2704
K (multiplier)= 5 measured time = 1083
K (multiplier)= 10 measured time = 543
K (multiplier)= 20 measured time = 270
K (multiplier)= 50 measured time = 109
K (multiplier)= 100 measured time = 56
K (multiplier)= 200 measured time = 30
K (multiplier)= 500 measured time = 14
So, predicting runtimes by scaling (acceleration, velocity,
feed) may be good enough for this example for scaling
factors up to about 100. For higher scaling values (or
shorter gcode programs), time offsets unrelated to motion
and/or second-order affects reduce the usefulness of the
prediction -- i didn't investigate further.
--
Dewey Garrett
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
