LinuxCNC S-Curve Accelerations

Hi,

A video of the Ruckig lib testing a 6 axis arciera robot.
The robot perform's a gcode. A square 200x200mm and a square 50x50mm. Every square is a path starting at p{0,0,0}.
The video shows the acceleration at begin of path, deacceleration to end of path.

During the video i set a backward's move with a negative max_velocity value. Then the program is doing reverse motion.
Also i change the max_velocity during the move. During the path planning, value's can be changed.

user-images.githubusercontent.com/448801...9db-ffe94792e164.mp4

This implies that planning is inherently a non-realtime activity.
In my code example, the path planning is performed realtime at the servo-thread.

I am side stepping the feed override issue
In my code example setting the feed override is as simple as set the max_velocity to a different value.
Increasing the jerk value, will also invoke the live max_velocity i have seen.

one thing i will have to think about is how to calculate a gcode corner g-force impact, and anticipate on this.

Grotius let me know if you would like testers for your component.
-automata
The github code is updated. But in a few day's i maybe have something plug and play to download.





 

A video with oscilloscope.

Hi,

A video with ocsilloscope and the ruckig trajectory component.

The ruckig component is now more ore less a stand alone motion planner.
Today the ruckig component was given the gpr library. It now can read a .ngc gcode file.



 

Hi Grotius,
Excellent work.
As I understand your component, currently, the gcode can be read at startup loading of the component.
The component will then issue a rapid move to the start of the gcode from current position. Then execute the gcode provided.

Could the next step be to make a motion / blocks queue and keep updating the blocks from the queue?
The gcode / motion blocks queue will be supplied from a user program that reads gcode and lines up the codes in a queue for execution?
This is what linuxcnc does inside the motion component.
-automata

Hi Automata,

The trajectory component can be used as stand alone motion planner now. Even without graphical gui it works.
All connections can be made from within the hal environment. I think this is nice.
I have to code the euler angles. For the rest it works quite nice so far.

As I understand your component, currently, the gcode can be read at startup loading of the component.
The gcode can be read when you want. I had to think a bit about this. It can be done in 2 way's. The first is the best.
1. We use hal_port to pass the gcode.ngc file path to the trajectory component. Then a hal_pin will load the gcode. Old gcode's will be removed.
2. The component can pop-up a filechooser dialog. This is now commented out in the source, but can be handy in some cases.

The component will then issue a rapid move to the start of the gcode from current position. Then execute the gcode provided.
Yes there is indeed a rapid G0 initial move from the current tcp position.
A run_from_line can be done. A hal_pin is used to set the line-number. A tcp xyz tooloffset can be given to hal_float pins.
A hal_pin "run" wil run the machine. Stop, Pause, Resume, is present. All with nice stop dcc conditions. No instand stops.
A hal_pin "enable" to enable the component. Can be connected to emerengy system.

Could the next step be to make a motion / blocks queue and keep updating the blocks from the queue?
I don't understand what you mean by this question. The internal code uses gcode blocks. A path is a collection of blocks.
The m3, m5, m7, m8, m9 are now working. Hal_pins are ready for this. I have to code the S[power,rpm].

The gcode / motion blocks queue will be supplied from a user program that reads gcode and lines up the codes in a queue for execution?
The component just read's the gcode.ngc file with help of the internal gpr c++ lib. This is a universal gcode reader. Then i convert this
data to more detailled gcode blocks. The gcode is already lined up, when readed in from the textfile.
In the component the path's, m-codes are loaded in memory. Then synchronized with the ruckig trajectory lib, we also perform the m-code's etc.

Hi,

The trajectory component is working. The jog is implemented. Auto mode and jog mode works nice.
A improvement is to expand the hal input code with individual xyz vel, acc, jerk values.
Mdi has to be finished.
It can be interfaced with halcommands. I made a halcmd gui for example wich is provided with the github source.
To load the trajectory component, have a look here.  

You are a force of nature.

After a few day's of coding, i can present a updated s-curve c-c++ library.

Over time, this is my third attempt to write a s-curve lib.
In the previous attemp's it had no acceleration begin and or end values. That is included in this version.

It's a shared library with a nice performance.
It can be used to request complete motion blocks.
It can also be used to request a acceleration or deceleration stage.
It has a c function interface. Requests from the hal component (kernelmodule) can be done.

It can now handle almost all situations, like acceleration begin/end values. Velocity transitions etc.

Related to Ruckig:
The s-curve-motion-planning is supposed to have a absolute accuracy in crossing waypoints with end velocity, wich is a problem for the Ruckig c++ library.
In Ruckig we have the bounce effect, and out of scope accuracy when crossing waypoints with end velocity.
Ruckig crashes  in a rt environment when setting down the velocity to 0.001 on longer paths for a unknown reason.

github.com/grotius-cnc/s-curve-motion-planning
 

Just curious how far do you think this is from being able to use on an actual machine in Linuxcnc to run G-code?

Hi Todd,

If someone can integrate the library into the lcnc motion planner it could be used.
I have no experience with the lcnc trajectory planner source code. But integrating should take a few day's of work including
the investegation process.