Feature request: Different acceleration for rapid and feed moves
Yes but there is present unlocated G-codes, for axample G0.1 etc.
Shu wrote: Remap G-code linuxcnc[/url] I G0 can't be remapped.
Note that the ini.pins are not sampled in realtime
or when G-code is running
Inihal pins are part of the userspace task module ($ man milltask) and
sampled at the interval set by [TASK]CYCLE_TIME. If
unspecified, the default interval is
DEFAULT_EMC_TASK_CYCLE_TIME=0.100. Many sim configs use
0.001 (seconds), pncconf and stepconf use a value of 0.010
(seconds). The inihal pins are read continuously but they can
only affect trajectory planning when the interpreter is idle
_OR_ when the trajectory planner updates its plan after a
synchronization command (commonly called a queuebuster).
So, one can 1)change an inihal pin, then 2)force a
synchronization, and 3)have the updated ini value used for
the next trajectory calculation _provided_ that task has
read the updated pin value and propagated the change to
motion before the trajectory planner plans the
Example (attached sim config demo.tar shows altered max_velocity
and max_acceleration for the x coordinate during a simple program):
1) Hal pin writes (M68) do _not_ synchronize but can be used
to set an inihal pin from gcode (or mcode) by netting the
inihal pin to a motion.analog-out-* pin
2) The simplest sync command is a hal pin immediate read:
M66 En L0. This synching read command can be used to read
the updated inihal pin (netting to a motion.analog-in-*
pin) to verify that the new value has been propagated from
the task module to the motion module.
3) As noted, response to inihal pins is _not_ realtime but using
an intervening synchronization read seems to always work in
my tests. To 'guarantee' acceptance of an updated ini hal
pin, the gcode should verify the updated inihal pin value
before continuing and if necessary issue additional sync
command(s) -- this is not done in the attached example, the
updated values are just printed with (debug,) commands.
4) With more testing (2.8 branch), i think that the mentioned
verification is not required but recommended as I tested only
simple programs with no subroutines or structured
code (loops etc).
how to ditch m codes to change acceleration before and after
every g0 entirely?
As mentioned, a remap (G0.n) would be a good method.
Alternately, a filter program can be used to find all lines
with G0 and surround them with the codes needed to alter the
inihal pin values for accel settings (with synching reads).
2.3. [FILTER] Section
Example filter (lightly tested):
$ chmod 755 ./g0filter.py # execute permissions $ cat g0filter.py #!/usr/bin/env python #------------------------------------------------------- # Note: create nets in a POSTGUI_HALFILE or APP file: # net :xa motion.analog-out-00 ini.x.max_acceleration # net :ya motion.analog-out-01 ini.y.max_acceleration # net :za motion.analog-out-02 ini.z.max_acceleration # set as required: x_accel_pin = 00; x_accel_slow = 1; x_accel_fast = 100 y_accel_pin = 01; y_accel_slow = 1; y_accel_fast = 100 z_accel_pin = 02; z_accel_slow = 1; z_accel_fast = 100 #------------------------------------------------------- import sys infile = open(sys.argv,'r') lines = infile.readlines() infile.close() g0_in_progress = False # handle consecutive g0 lines # ensure slow accels at start: print("M68 E%d Q%.2f (slow)" % (x_accel_pin, x_accel_slow)) print("M68 E%d Q%.2f (slow)" % (y_accel_pin, y_accel_slow)) print("M68 E%d Q%.2f (slow)" % (z_accel_pin, z_accel_slow)) print("M66 E0 L0") # read to synch for line in lines: line = line.replace("\n","") has_g0 = line.replace(" ","").upper().find('G0') >= 0 if has_g0 and not g0_in_progress: g0_in_progress = True print("M68 E%d Q%.2f" % (x_accel_pin, x_accel_fast)) print("M68 E%d Q%.2f" % (y_accel_pin, y_accel_fast)) print("M68 E%d Q%.2f" % (z_accel_pin, z_accel_fast)) print("M66 E0 L0") # read to synch print(line) # first G0 line continue if has_g0 and g0_in_progress: print(line) # multiple consecutive G0 lines continue if not has_g0 and g0_in_progress: g0_in_progress = False print("M68 E%d Q%.2f" % (x_accel_pin, x_accel_slow)) print("M68 E%d Q%.2f" % (y_accel_pin, y_accel_slow)) print("M68 E%d Q%.2f" % (z_accel_pin, z_accel_slow)) print("M66 E0 L0") # read to synch print(line) continue else: print(line) # unalteredline sys.exit(0)
Ini file settings for g0filter.py in config directory:
[FILTER] PROGRAM_EXTENSION = .ngc G0_filter ngc = ./g0filter.py
What g64 setting do you use?
Yes it's jerk. The following error is almost the same with low and high acceleration values. The machine has encoders at the servos, but no direct feedback. I'm not sure if there is any way to incorporate direct feedback on a moving gantry of that size. The jerk can be observed, e.g. bad surface quality when machining simple wooden test pieces, lots of overshoot and ringing when measured directly at the spindle head with a glass scale.
cmorley wrote: I'm curious - is it the high acceleration on feeds creates 'jerk' or creates following errors/missed steps?
What g64 setting do you use?
The head of the large moving gantry is flapping around while the servo thinks it's on point. The machine is just not stiff enough and has some wear.
Retrofit with a Beckhoff TwinCat (jerk can be limited) works well.
cmorley wrote: What g64 setting do you use?
I think the default of the machine and tool changing is run with G64 (no further parameter). Smooth
For actual programs G64 is in the post processor header with P0.04-P0.2 (in mm).