New Trajectory Planner - Testers/programs wanted

Maybe post your hal and ini files? there is some dirivative calculaters in the main hal file...

ie (this is a sample - you cannot just copy and past this in - have to make it work in your hal..)
I bolded what I think should be added...


# load 6 differentiators (for velocity and accel signals
loadrt ddt names=ddt_x,ddt_xv,ddt_y,ddt_yv,ddt_z,ddt_zv
# load additional blocks
loadrt hypot names=vel_xy,vel_xyz

# add motion controller functions to servo thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
# link the differentiator functions into the code
addf ddt_x servo-thread
addf ddt_xv servo-thread
addf ddt_y servo-thread
addf ddt_yv servo-thread
addf ddt_z servo-thread
addf ddt_zv servo-thread
addf vel_xy servo-thread
addf vel_xyz servo-thread

# create HAL signals for position commands from motion module
# loop position commands back to motion module feedback
net Xpos axis.0.motor-pos-cmd => axis.0.motor-pos-fb ddt_x.in
net Ypos axis.1.motor-pos-cmd => axis.1.motor-pos-fb ddt_y.in
net Zpos axis.2.motor-pos-cmd => axis.2.motor-pos-fb ddt_z.in

# send the position commands thru differentiators to
# generate velocity and accel signals
net Xvel ddt_x.out => ddt_xv.in vel_xy.in0
net Xacc <= ddt_xv.out
net Yvel ddt_y.out => ddt_yv.in vel_xy.in1
net Yacc <= ddt_yv.out
net Zvel ddt_z.out => ddt_zv.in vel_xyz.in0
net Zacc <= ddt_zv.out

# Cartesian 2- and 3-axis velocities
net XYvel vel_xy.out => vel_xyz.in1
net XYZvel <= vel_xyz.out

bjames28 wrote:

Hi Sam,

Thanks for the hint, that solved my issue with git.
I was able to compile and I have now working new TP. Great!

I wanted to test your pyvcp panel with peak acc/velocity display.
I put the check_constraints.hal and postgui.hal in the appropriate directory,modified the INI file accordingly, the panel appears in the right place, but the axis Acc/Vel values are not updated, all remain zero.
The cycle time works.

What else do I need to modify to get the numbers updated?

Best regards:
James

rellenberg wrote:

ARC_BLEND_OPTIMIZATION_DEPTH = 50 (Lookahead depth in number of segments)

To expand on this a bit, you can choose this value somewhat arbitrarily. Here's a formula to estimate how much "depth" you need for a particular config:

# n = v_max / (2.0 * a_max * t_c)
# where:
# n = optimization depth
# v_max = max axis velocity (UU / sec)
# a_max = max axis acceleration (UU / sec)
# t_c = servo period (seconds)

So, a machine with a maximum axis velocity of 10 IPS, a max acceleration of 100 IPS^2, and a servo period of 0.001 sec would need:

10 / (2.0 * 100 * 0.001) = 50 segments to always reach maximum velocity along the fastest axis.

In practice, this number isn't that important to tune, since the lookahead rarely needs the full depth unless you have lots of very short segments. If during testing, you notice strange slowdowns and can't figure out where they come from, first try increasing this depth using the formula above.

If you still see strange slowdowns, it may be because you have short segments in the program. If this is the case, try adding a small tolerance for Naive CAM detection. A good rule of thumb is this:

# min_length ~= v_req * t_c
# where:
# v_req = desired velocity in UU / sec
# t_c = servo period (seconds)

If you want to travel along a path at 1 IPS = 60 IPM, and your servo period is 0.001 sec, then any segments shorter than min_length will slow the path down. If you set Naive CAM tolerance to around this min length, overly short segments will be combined together to eliminate this bottleneck. Of course, setting the tolerance too high means big path deviations, so you have to play with it a bit to find a good value. I'd start at 1/2 of the min_length, then work up as needed.

rellenberg wrote:

ARC_BLEND_RAMP_FREQ = 20

Another trade-off between smoothness and speed is controlled by this cutoff frequency. The benefits in terms of smoothness are explained in the prev. post, but it wasn't clear what this costs you in terms of performance. You can characterize the worst-case loss of performance by comparing the velocity that a trapezoidal profile reaches vs. the ramp:

# v_ripple = a_max / (4.0 * f)
# where:
# v_ripple = average velocity "loss" due to ramping
# a_max = max axis acceleration
# f = cutoff frequency from INI

For the aforementioned machine, the ripple for a 20Hz cutoff frequency is 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is only a worst-case estimate. In reality , the trapezoidal motion profile is limited by other factors, such as normal acceleration or requested velocity, and so the actual performance loss should be much smaller. Increasing the cutoff frequency can squeeze out more performance, but make the motion rougher due to acceleration discontinuities. A value in the range 20Hz to 200Hz should be reasonable to start.

Finally, no amount of tweaking will speed up a toolpath with lots of small, tight corners, since you're limited by cornering acceleration. Still, if you see a slowdown that you think shouldn't be there, post the example here. There's always the chance that there's a bottleneck that we missed.

I tried to get the latest, but am receiving the error:

cnc@linuxcnc:~/linuxcnc-rc1$ git branch --track circular-blend-arc-rc1 origin/circular-blend-arc-rc1
fatal: Not a valid object name: 'origin/circular-blend-arc-rc1'.

I received this after following the new instructions found in the first post. I have a version I downloaded sometime in early February loaded in linuxcnc-beta which went well.

Any help appreciated. Thanks.
Paul

well - crap. I thought I had edited the first post.. Rob did some work to get his branch to work in current master so he is up to rc3. (rc1 was deleted it seems)

Could you try instead.

git branch --track circular-blend-arc-rc3 origin/circular-blend-arc-rc3
git checkout circular-blend-arc-rc3
cd src
./autogen.sh
./configure --enable-run-in-place
make
sudo make setuid
cd ..
. ./scripts/rip-environment
linuxcnc

Paul wrote:

I tried to get the latest, but am receiving the error:

cnc@linuxcnc:~/linuxcnc-rc1$ git branch --track circular-blend-arc-rc1 origin/circular-blend-arc-rc1
fatal: Not a valid object name: 'origin/circular-blend-arc-rc1'.

I received this after following the new instructions found in the first post. I have a version I downloaded sometime in early February loaded in linuxcnc-beta which went well.

Any help appreciated. Thanks.
Paul

That did it! Thanks. Sorry I couldn't figure it out on my own.

I'm having trouble getting the rc3 download to compile & would appreciate some pointers -

environment -
new (5/28/14) iso download system install.
source from github.com (git.linuxcnc.org was busy every time I tried). source version was master, per the incantations prescribed on the download page.
master branch compiled without complaint.

today, I pulled the rc3 branch per the instructions on page 1 of this thread & launched the usual make process. make stopped with

(much compilation)

touch po/linuxcnc.pot
cp emc/kinematics/tc.h ../include/tc.h
cp: cannot stat `emc/kinematics/tc.h': No such file or directory
make: *** [../include/tc.h] Error 1

when I looked, the include directory contained a tc.h file. to investigate, I copied that file to src/emc/kinematics, reran make, and got

( again, much makery)
. . .
CC [M] /home/techno/lcnc-dev/src/emc/tp/blendmath.o
CC [M] /home/techno/lcnc-dev/src/emc/motion/motion.o
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-122-rtai'
In file included from /home/techno/lcnc-dev/src/emc/motion/motion_debug.h:19,
from /home/techno/lcnc-dev/src/emc/motion/motion.c:19:
/home/techno/lcnc-dev/src/emc/kinematics/tc.h:36: error: conflicting types for ‘PmLine9’
/home/techno/lcnc-dev/src/emc/tp/tc_types.h:59: note: previous declaration of ‘PmLine9’ was here
/home/techno/lcnc-dev/src/emc/kinematics/tc.h:42: error: conflicting types for ‘PmCircle9’
( many more type errors)

so, clearly just moving the file ain't the answer ( I didn't expect it would be).
Anyone have a clue why a download from yesterday isn't compatible with the fresh system install?
I haven't seen any refs to later versions than rc3 - did I miss a later release?

thanks in advance

-ldw

I've seen similar things when checking out the circular arc branch after building master. Try running make clean first and see if that helps.

Bingo - make clean gave a happy compilation. Now on to checking it out. Thanks

-ldw

ARC_BLEND_ENABLE = 1 : self-explanatory, disable the new TP method entirely.

Does this statement turn off the new TP and revert back to the old TP?

I'm not sure if this was answered elsewhere, but I'll answer here too in case.

That flag disables circular arc blending and uses parabolic blending for everything (what the stock TP does). In that sense it will revert to the previous behavior. However, due to some major refactoring, you'd still be running modified code. One difference you'll see, for example, is that acceleration on circular arcs is lower in my branch, which fixes a minor acceleration violation in some conditions.