Hi,
It's in general a good idea to test the s-curve implementation from within a component. It will keep it simple. But then
you also need a component style gcode reader, including function's like "start from line" etc.
My current strategy after more coding today :
- Read the gcode file into a vector of paths. A path is a motion from M3 to M5. Or a rapid G0.
A path has a total motion lenght.
- The Ruckig lib will perform the motion of each path. Today i did this succesfully in a 1ms live mode.
Then during execution of the motion, parameters like acc_max, vel_max, jerk_max can be modified during the motion!
This is realy great! Also moving backwards, motion reverse is no problem.
- In the above stage's no real x,y,z interpolation is done so far. Just one DoFs is used for a lineair path planning.
Imagine arc lenght's and line lenght's combined as a total path lenght.
As a result of the above implemenation :
The tcp x,y,z and tcp euler x,y,z interpolation can be done from the position of the one DoFs.
With this result the kinematic model can be driven.
The kinematic model, for example a 6 axis robot can then use a 6 DoFs system that control's the kinematic model motion.
Hi Grotius,
Excellent strategy to make a separate motion hal module for testing and proveout.
I am also working on simillar lines to making a multiaxes motion planner and playout module.
From my point of view, LinuxCNC does the entire motion planning in the realtime context (same as ruckig as it is an online planner).
However, the main task entrusted to linuxcnc is playout of pre-known gcode. This implies that planning is inherently a non-realtime activity.
I am side stepping the feed override issue though and do have a good solution for that too with my strategy (one that has been commercially deployed in more than a few thousands of machines worldwide from my previous job).
The motion plan of a path can be represented as a queue of third order (for jerk limited planning) polynomials. The complete plan can be optimized offline (i.e. in the non-rt part of the program i.e. in milltask in LinuxCNC) and the result will be a series of polynomials.
P_1 = A_1t^3 + B_1t^2 + C_1t + D_1, valid from 0-tf_1 with startpoint of the axes as Xs_1, Ys_1,Zs_1,As_1,Bs_1,Cs_1,Us_1,Vs_1,Ws_1 and end point as Xf_1,Yf_1,Zf_1,Af_1,Bf_1,Cf_1,Uf_1,Vf_1,Wf_1. here P_1 represents the distance travelled along the path represented by the polynomial. Simillrly an arc representation can also be made with P_n representing either the distance moved on the arc OR even the angle advanced along the arc movement as it is monotonic increasing. Only constraint on P_n has to be is that it is monotonic and can be scaled between 0-1.
The motion or the realtime module does only a playout of the polynomials with a known time advance parameter which is the servo-thread time i.e. 1ms in most installations although it can be different. The polynomial is sampled at servo-thread time and new values of P_n are computed and using the Xs_n and Xf_n the value of the X coordinate can be derived.
The feed override can be handled by changing the time-advance parameter. So in order to slow down from the planned rate, the polynomial is sampled at a rate lower than 1ms (servo time) and vice versa for faster movement.
Now the trajectory planning i.e. computation of the polynomials can be done with a standard trapezoidal planner. Tangential Jerk limitation can be added by replacing the acceleration and deceleration polynomials with 2 or 3 3rd order polynomials that perserve the average acceleration and execution time (strategy outlined here
forum.linuxcnc.org/38-general-linuxcnc-q...accelerations#102589
).
Grotius let me know if you would like testers for your component.
-automata
