LinuxCNC S-Curve Accelerations

Hi,

Got sc_engine with the sc_planner running.



(link to image source)

What shoud we do next?



 

Hi,

Just a little update. Last day's i coded the sc_planner into a state-machine.
A state machine is a code strategy that also opengl uses.
That is now finished, result seems ok.

This picture show 3 motions, the first motion has a end velocity transition to next motion.
In the second red curve, a "vm" interupt from 10 to 9 is done.

If you perform a pause in a end velocity motion, the motion will stop. Then the planner calculates
how to restart. This are tricky things.

I will try to focus on a look ahead function now. This function should be valuable for getting the perfect
end velocity's when passing sharp corners in a traject. I think this will be a head scratcher somehow.
image_link

Hi,

A little update.

The past day's i coded a scurve pid controller.
It works like a lcnc stepgen.so or pid.so component, but then especially for a scurve motion profile.

This was a quite difficult task to get it coded.

The complexity lies in finding the correct period of a scurve, given only 4 things :

1. Current position
2. Current acceleration
3. Current velocity
4. Target position.

This finding of the correct scurve period is one out of seven.

t1,t2,t3,t4,t5,t6,t7

And from there what should be the next motion cycle step.

I figured it out, after a few attempt's over the day's it worked.

What the sc_pid does :

1. Get the motor on the target position as quickly as possible using scurve motion profile.

When is a scurve pid usefull :

1. To trigger any following errors between the joints and the path planner.
2. To connect servo or stepper motors to, and drive them with scurve motion profile.

Hi,

I have little problem to share with you.

In this example the pid-controller is connected to the y-axis of the motion planner.
To trigger following errors.

The four red curve's represent a square of 100x100mm.

The first and third red curve's are the y-axis motions. The cyan curve is the pid velocity, trying
to follow the red curve. You see it does follow, but not quite accurate.

If i play a little with the pid acceleration, and dv value it will become better, but it's not what i hoped for.
As stand alone, the pid works quite nice. But givin it a new position every 1 ms, is a problem.
Maybe use another simpler aloritme for this?



Here another test is done. At the start of motion the pid recieves a 100mm target point, just
to test the pid curve.
It shows a little offset, but when i start the planner and pid at the same time, the curve's
are identical. An sich this is good news. Especially because the pid and the planner uses
a slightly different algoritme.




 

I tried to understand your problem, but unfortunately it is completely unclear (to me) what you are trying to do here. It seems there is no connex to linuxcnc TP whatsoever, and I don't understand what your PID is.

PID usually means proportional - integral - derivative controller, which says how to fold back an error signal (difference between setpoint and feedback) onto your output to minimise the error signal. I looked at your PID code and I don't find anything resembling PID control, not even a control loop, so at least naming is misleading.

Some other observations / suggestions:

* get a proper git client and give commits a meaningful commit message if you want people to collaborate
* naming things is hard
* in theory, all transitions need a full stop, not only 90° line line transitions. even on a "shallow" line line transition, you come in with e.g. X-speed vx1 / Y-speed vy1, and you want to go out with vx2/vy2, with sqrt(vx1^2+vy1^2) = sqrt(vx2^2+vy2^2) (the feedrate), that would need instantanous change of speeds in the transition point, which isn't possible.
* you can tell the machine that some compromise between exactness of path and slow down of feedrate is acceptable (see G64), which will allow the TP to smooth transitions. It will lead to rounded corners and similar inaccuracies, but as a real machine can't respond infinitely fast and has limited mechanical accuracy, there is no "exact" path following anyways.

It looks like a lot of effort went into this. "explorative coding" can be fun for it's own sake, but in this case I fear it won't go very far in direction of a solution.

Hi rmu,

Thanks for comments.

The pid has a control loop. Maybe it doesn't look that there is one at first sight.
The sc_pid library has no internal timer or thread. It only has a update handle that has to be connected to a external thread.

In the sc_pid_gui there is a 1ms timer, this timer updates the pid  :
pid->sc_update();

It runs every 1 ms to process next curvature step. It's coded to try to follow the main planner output.
The name could be misleading for you, sorry for that.

I could name it like : position_follower instead of pid.

However, the position_follower as stand alone app works nice.
When updating the tarpos every 1ms, the output is not acceptable.

An sich this is no problem for now. We could fall back to the lcnc's stepgen.so or pid.so for this task.
I already have a idea to solve above problem, but has no first priority right now.

About the git, when there is no contribution made by others, until that time
i can fast upload the project by dragging it into the files upload section of
the explorer.  By terminal upload a lot of copy and paste has to be done to do a commit.
That's the reason.

I fear it won't go very far in direction of a solution.
It's certainly explorative coding. I keep optimistic about this project.
The solution don't have to be there the next day. I think it's important to keep progress.

Soon i hope to explore mr. Garrets comments.

in theory, all transitions need a full stop

Personally i don't like the G64P0.001 theory. I am more fan of always use max accuracy at all times if possible.

In my view it's not that lcnc solution is the only solution.
Mach3 does a quite good job in keeping accuracy over waypoints.
Mach3 goes out of path when velocity is set to high.
I never done a reverse engeneering on mach3 with nsa ghidra, there is one mach3 file wich can be interesting.
did a reverse on Drafsight a few times. This was
really helpfull.

that would need instantanous change of speeds in the transition point, which isn't possible.

For designing a solution to get a nice transition, every solution has it's up's and down's.

To get the planner finished in coming day's i started with in my view the most simple solution.
It could alway's be replaced by a improved one.

When you take a look at the sc_look_ahead, there are some solutions in progress.

In short :
1. Iterate over the gcode, calculate speeds for corners between : line-line, arc-line, line_arc, arc-arc.
2. When iterating over a arc, calculate the gforce. Set maxvel for arc.
3. Iterate over the gcode, ve=0 at G0, for G1,G2,G3, calculate speed transitions.
4. Iterate backwards over the gcode to verify speed transitions backwards.

This will hopely cover most of the path problems. If there remain problems it's quite easy to append
extra path rules. If above solution is not working at all, it could be replaced by something better.











 

Hi grotius,

as quoting in this editor really is painful, I try to give some comments without directly quoting context.

How drag/drop can be quicker than using git from the IDE or comand line I don't understand. Definitely no mandatory copy pasting involved. And you would get nice history of what changed when and why.

The G64 stuff is not a theory, it is kind of a standard, and provisions like that exist in other machine controllers too. I have never used nor seen mach3 in action, but AFAIK it is also derived from NISTs enhanced machine controller.

As I mentioned in my post, exact following is not possible, so you have to make some compromises. The trajectory should be modified to keep feedrate near programmed value while obeying G64 tolerance setting, and acceleration/jerk limits of joints.

The rest you describe in "short" already happens in linuxcnc trajectory planning. On youtube you can find a video from Rob Ellenberg that explains how optimization of transitions are done. Don't have the link handy, but it should have already appeared somewhere in this thread.

I am cheering for Grotius. I have seen him transition from Mach3 to Linuxcnc, mastering ethercat to a high level and teaching himself how to program in C from a zero base. In a few short years, he is now  tackling complex problems like trajectory planning and jerk limiting which is nothing short of amazing. What he lacks in knowledge, he more than makes up for in tenacity. I am certain he will achieve his goals and I sincerely hope he can share his success with the Linuxcnc project. 

There has been an awful lot of talk about jerk limiting here, but there is really only one person who has really made progress. Whilst he might be unconventional in his approach, I'm sure he will eventually teach linuxcnc how to limit jerk.

rodw: I didn't intend to sound negative. back to lurk mode for now.