scurve trajectory planner

Hi Arciera,

Thanks for feedback.
If the acc in the ini file is 50, the scurve is max 2*50=100 at inflection point. This is normal.

However. I run the same file, and i got no spikes.
This is the first corner :
 

Maybe you did not update the clothoid lib? U used clone recursive wich is needed.
Or git is messed up.

For sure i just did a push for scurve planner, clothoid lib, scurve as up to date.
That's annoying when you have 3 repository's depending on each other.

Hi Arciera,

The scurve planner takes the [TRAJ] trajectory acceleration : MAX_LINEAR_ACCELERATION = 200
When tpAddLine, tpAddCircle is done, it gives this 200 value to the planner.
The scurve acceleration max is then 2*200=400 at inflection point.

However the planner does not lower the acceleration to a specifik max joint acceleration at the moment.
We have acces to all joint max acceleration values.

We could reduce max acceleration to satisfy max joint acc. We implement this without any problems.

Congratulations on the development!!!!!

I was able to test using the files, in version 2.10..

I have a machine here with ethercat and I can get 30mxmin, I would like to put it on it to test...

I tried to copy only the .so file in the modules folder, but I'm sure that this is not the correct way...

How do I make it work in version 2.94 normally???

 

Grotius, all your work on s-curve and the clothoid path smoothing is absolutely amazing, thanks so much for doing all this! Really exciting to see these features in an open-source controller.

Regarding the tangential knife angle, instead of just having the data as a hal pin, is it also possible to have the motion planner command a rotary joint/axis to complete this motion?

The problem with using the hal pin to control a rotary axis is that the motion won't be smoothly blended, and the rotary axis will have to accelerate fast to avoid significant deviation since (unless cutting a straight line), it's essentially always playing catch-up to the position where it should be.

So, to implement this, it would mean calculating the tangential knife angles when the clothoid is calculated and adding these rotary joint moves to the queue? And then when loading the motion planner, specifying which joint is to be used in this manner?

I understand this could get complicated if you do also want the rotary axis to be controllable by the operator/G-Code as well, in which case the tangential knife angle could maybe act as an incremental offset from the joint commanded position (and normally you would set the axis to 0deg to use it with the motion planner tangential knife). And as the user you'd probably define a custom M-Code to enable/disable this functionality if one isn't already implemented.

Sorry if this is a slightly messy explanation, I just thought that now was a good time to mention it while this feature is under development. And thanks again for all your work on this!

@DauntlessA
Its not necessary (or desirable) for the TP to command the motor. Instead, another real time component would read the heading and command the tangential knife motor. The strength of Linuxcnc is its modular design so don't break that.
When you see how fast Linuxcnc can respond and move position on a plasma cutter, I don't think it would be an issue to keep up with the knife.

Rod,
I might have explained things a bit poorly when I talked about the axis 'catching up'.

It's not how fast LinuxCNC itself responds, its the fact that axis motion commanded via hal pin isn't added to the queue. This means that if the rotary axis cannot move fast enough at a sharp corner, the other axes will not slow down in proportion. To compensate, you would have to feed slowly at all locations or write a program/post which implements smooth changes to slower speeds at corners.

I've had this issue using external offsets to simulate coordinated motion for surface mapping. This isn't a criticism of external offsets, it's just not the most ideal tool for that purpose if your X and Y axes are faster than the Z axis compensation is. This is because a standard implementation is commanding the Z offset using a hal pin corresponding to the current XY position, so you need to slow down at all positions to guarantee an acceptable Z positional tolerance. A tangential rotary axis will definitely suffer from this type of issue on sharp corners.

I understand what you're saying, and modularity is the aim for LinuxCNC, but surely since this tangential rotary axis I'm describing is ideally in coordinated motion with the other axes, it makes sense for it to be directly controlled by the trajectory planner? And especially since I'm describing a case where the tangential angle is both generated by and used by the trajectory planner?

The trajectory planner already directly commands axes, so allowing it to slave a rotary axis to an attribute of the linear axes calculated by itself could make sense.

Also, please ignore some of my thoughts above about how the rotary axis might also be commanded with G-Code as well, I admit I got a bit carried away thinking about a more complex implementation before settling the basics. I just wanted to argue that there are benefits to this approach.

And, sorry if I've gone a bit off-topic for the core trajectory planner discussion, this is discussion of a hypothetical feature after all! Happy to carry on discussing this somewhere else!

I think there is more to consider when commanding a tangential knife. eg when do you lift it on a sharp corner? When do you have to overrun and reposition on a corner? I don't know anything about tangential knives but I am guessing the  motion for the knife that a supplier of mine uses to  cut my parts from rubber sheet is a bit different to a circular saw a stone mason uses.

One issue with external offsets is that you need to allocate a percentage of velocity and acceleration of the axis to the offsets. In some applications (eg plasma cutting) motion and offsets are mutually exclusive so you can allocate 100% of motion to the offsets by doubling the velocity and acceleration and using a offset ratio of 0.5

I've never experimented with anything but wouldn't you be able to to use joint.N.motor-pos-fb to align the knife?

@Eneias_eringer,

To install it on different lcnc versions, you need to patch the original lcnc version first.
If you use a tool like :https://www.diffchecker.com/text-compare/
you can compare the files to path, with your current file. And see the difference between them.
This example shows how to patch the current lcnc git clone.

The path includes replacing 4 files, and needs at least 3 to be replaced or modified :

1. motion.c
2. tp.c
3. tp.h

In general : add the blue code after the existing green code.

1. motion.c
~Line 242 :

    tpMotData(emcmotStatus
             ,emcmotConfig
             );
    tpMotExtraData(emcmotCommand,
                   emcmot_hal_data
                   );

2. tp.c
~Line 64

static emcmot_status_t *emcmotStatus;
static emcmot_config_t *emcmotConfig;

emcmot_status_t *emcmotStatus;
emcmot_config_t *emcmotConfig;
emcmot_command_t *emcmotCommand;
emcmot_hal_data_t *emcmot_hal_data;

Note : in latest lcnc version some dev now used "static emcmot_status_t *emcmotStatus;".
We don't use that.

3. tp.h
~Line 20
#include "tcq.h"
#include "mot_priv.h"

~Line 85
               ,emcmot_config_t *
               );

// Forward decleration.
void tpMotExtraData(emcmot_command_t *
               ,emcmot_hal_data_t *
               );

Then i just tested a git clone and a patch by :

This worked.

When above is working, the last thing to do is install the scurve code.

We need google's ceres solver to be installed :sudo apt-get install libceres-dev
Then to install the scurve, you can invoke the ./build_cmake command from within the /cmake directory.
This then builds & installs the scurve component, clothoid lib, scurve lib etc.
 

For the tangential knife application, at the moment there is only a rotational value output available, wich
can be used in hal to connect to a motor or device.
There is no additional logic in the planner for the tangential knife.

I understand the concerns off DauntlessA regarding the use of the tangential knife when there is no additional
logic included.

I see basicly 2 solutions at the moment.

Solution 1 Basic :
Use the hal rotational value from the planner, connect the tangential motor in hal.
Then be sure your gcode uses ramp in path's so that the direction vector is always in the right direction.
In my perspective it's better to avoid straight z moves, but always a z move containing some xy changes, wich will
direct the tangential rotation in the path direction.

Solution 2 Advanched :
The planner has at the moment 4 build-in, you can call it "post processors". overview link
These are used to verify the planners behaviour at runtime. And they are used as fallback option and as a template layout.

We can easely add more post processors for special applications.

That's why the infrastructure in the planner is build up this way.
You just need to copy one off the current post processor .h header files, and edit it your way.

Then for example, we copy the "file_path_clothoid" to a new path algo: "file_path_clothoid_tangential_knife".

Then when doing the tpAddLine or tpAddCircle, we can add rotational start-, end values for a-axis, wich can be used for the
tangential knife device.

From the moment the a-axis has rotational tangential knife values.
It's part of the motion control system.

During the tpAddline & tpAddCircle we also look if a-axis has only motion, and xyz has motion or xyza has motion.
This makes difference in calculating speeds & trajectory length's.

So in fact a lot can be customized here. The planner has a clean modular infrastructure. And the oversight is not that hard to
follow.

I have build a cnc with tangential knife device years ago. It was sold to a shoe company to cut shoes from leather.