Feature request: Different acceleration for rapid and feed moves

aleksamc
Offline
Platinum Member

15 Jan 2020 14:21 - 15 Jan 2020 14:22 #154921 by aleksamc

Replied by aleksamc on topic Feature request: Different acceleration for rapid and feed moves

Shu wrote:
Remap G-code linuxcnc[/url] I G0 can't be remapped.

Yes but there is present unlocated G-codes, for axample G0.1 etc.

Last edit: 15 Jan 2020 14:22 by aleksamc.

Please Log in or Create an account to join the conversation.

dgarrett
Offline
Platinum Member

15 Jan 2020 17:47 - 15 Jan 2020 18:16 #154939 by dgarrett

Replied by dgarrett on topic Feature request: Different acceleration for rapid and feed moves

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
post-synchronization move(s).

Example (attached sim config demo.tar shows altered max_velocity
and max_acceleration for the x coordinate during a simple program):

Notes:

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).

Last edit: 15 Jan 2020 18:16 by dgarrett. Reason: note 4)

The following user(s) said Thank You: tommylight, Shu

Please Log in or Create an account to join the conversation.

dgarrett
Offline
Platinum Member

16 Jan 2020 00:53 #154987 by dgarrett

Replied by dgarrett on topic Feature request: Different acceleration for rapid and feed moves

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).

Ref: linuxcnc.org/docs/2.8/html/config/ini-config.html
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[1],'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

Please Log in or Create an account to join the conversation.

cmorley
Offline
Moderator

16 Jan 2020 09:25 #155003 by cmorley

Replied by cmorley on topic Feature request: Different acceleration for rapid and feed moves

I'm curious - is it the high acceleration on feeds creates 'jerk' or creates following errors/missed steps?
What g64 setting do you use?

Chris

Please Log in or Create an account to join the conversation.

Shu
Topic Author
Offline
Senior Member

16 Jan 2020 09:58 #155006 by Shu

Replied by Shu on topic Feature request: Different acceleration for rapid and feed moves

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?

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.
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.

Please Log in or Create an account to join the conversation.

Shu
Topic Author
Offline
Senior Member

16 Jan 2020 10:05 #155008 by Shu

Replied by Shu on topic Feature request: Different acceleration for rapid and feed moves

here the open gantry with the large cantilever can be seen: www.instagram.com/p/B1Pipw6ACSN/?utm_sou...b_button_share_sheet

Please Log in or Create an account to join the conversation.

Shu
Topic Author
Offline
Senior Member

16 Jan 2020 11:12 #155014 by Shu

Replied by Shu on topic Feature request: Different acceleration for rapid and feed moves

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).

Please Log in or Create an account to join the conversation.

Time to create page: 0.960 seconds

Feature request: Different acceleration for rapid and feed moves

Attachments: