LinuxCNC S-Curve Accelerations

Hi,

Grey is S (distance) versus T (time). This grey line starts at xy:0,0
The grey line is scaled on the y-axis back to fit into the screen.
It's a quite unusual display. But it show's more or less how much distance is produced over time.

Cyan and red is the actual s-curve, cyan and red separates the convex and concave period's on both sides of the curve.
Where the color's change in the curve, we have the inflection point where the acceleration of the curve = 2* linair acceleration.
The color is not inline with convace or convex, it's just a separator color.
Black is the acceleration.

Nice - it's an interesting problem to work on!
Yeahh. It's quite boring to code math. But after 2 day's it works better then my previous attempt.
I really like the velocity sampling solution. My first solution was to find the intersection of 2 curves, but sampling
is much easyer.

Now working on the realtime buffer. The ingredients are :

2 buffers of 3000ms.
1 chrono high resolution clock
5 textfiles with each 3000 motion command lines to give the buffer meat.
1 portion off luck.

Today i started coding a buffer example to send xyz position's within a 1ms period.

I ended up with 6 buffers, each buffer containing 1000 lines, every line represents a interpolated motion command of 1ms.

I ended up using 2 main period's, acting together.

In each main period 3 buffers are loaded, time shifted, to prevent memory shocks.
In the main period the 3 buffers of the other main period are cleared time shifted and 3 new buffers are loaded into memory
also time shifted.

The result where within 1ms.

The process in a nutshell :

1. Load a sequence of textfile's from /tmp/ containing 1000 motion commands, each command (line) represents 1ms.
2. Loads the textfile into a vector line buffer of 1000 lines.
- The process of loading a textfile and loading it into a buffer takes about ~ 0.6 ~ 0.7 ms.
3. Then the mainloop is carrying out executing of the current active buffer, it empty's old buffers, and load's upcoming buffers.
4. In this case the s-curve, kinematics, etc are pre-processed. This makes it easyer to go ultra fast realtime.
5. The textfile is considered as fixed memory. I have to test what a robot program of 30 minutes will take on filesize.

1000 lines of motioncommands in a texfile is : 32.1 Kib every second. (0.03125 Mib)
= 60 sec * 60 min * 0.03125 Mib = 112 MiB for one hour of robot pleasure.

So far so good.

Slowly getting there! Below is the first test using axis_mm simulation:


The build and linking for this test was very crude: I built the planner object file separately (as a static library), copied into the linuxcnc object directory manually, and crudely hacked it into the linuxcnc linking.

I haven't been able to fully understand the linuxcnc build system yet. Look at the linking rule in src/Makefile : if I understand this correctly, object files are linked into "normal" object files (with a .tmp file name), then only some symbols - those marked with .rtapi_export - are exported/extracted into .sym files, and then, well, the two last lines I haven't been able to decipher yet. Anyone versed in the build system, please explain what's happening here.

Great work. I did play once making a different task module. If you have a look under the folders under /src/emc, each folder has a Submake file in it.

I made a copy of the src/emc/iotask folder to another folder and called it plasmatask.
I just had to tell the system to look in the new folder here
github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L136

Because task is not statically linked, thats all I had to do.
It only took half an hour to get this working so I could change my ini file to load the new task module

You may find if the object files are copied into the right folder by your submakefile, the system will look after itself. There seems to be a lot of wildcards for the file names in that linker section.

Hope that helps..

Thanks!

Was your plasmatask a separate module (.so/.ko) or was it part of some existing module?

I need to call Rust's dependency manager 'cargo' (kind of the equivalence to C's make) to build my code, which produces an archive file (which is just a collection of - quite a few - object files). This then needs to be linked into the motmod module.

It's not that difficult to write a special rule for motmod.so that takes care of this for uspace builds, but it would be nice to add some more generic support for Rust source files. That's why I feel I need to understand the build system pretty well.

When it comes to kbuild builds, support for Rust in the kernel is on its way , but it's still very early days. So I'm thinking it's a good idea to get jerk-limited jogs working well in uspace first, and then see where the kernel support is.

arvidb wrote:

Thanks!

Was your plasmatask a separate module (.so/.ko) or was it part of some existing module?

No it as just a short lived experiment (read 1 day). Andy had often said that there could be a need for a seperate task (and io) module for plasma, so I just made a copy of the existing modules and incorporated them into the build process as a proof of concept and subsequently loaded them from the ini file

The capability now included in plasmac.comp and supporting GUI's means going down this path is not warranted.


Sounds like what you need is the ability to load a seperate motion module

rodw wrote:

Sounds like what you need is the ability to load a seperate motion module

I'm not so sure about that: the motion module (motmod) contains lots of stuff, simple_tp (that I'm replacing) is just a small part. Look from line 1103 in the Makefile .

(It could perhaps be useful to keep motmod as it is and build an alternative motion module with jerk-limited jogging, but the problem I have to solve - how to add support for linking a motion module with a static archive built from Rust source - would be the same.)

I don't know anything about Rust and very little about the Make build process but it seems its all there. Such interoperability is supported in Rust. docs.rust-embedded.org/book/interoperability/rust-with-c.html

I would create a new folder under /src/emc/, Edit the SUBDIRS to execute that folder at compile time and have your submakefile call the rust build process having regard for all of the extra interoperability overhead mentioned on that link. Then you have an object file that culd be included in the link process.

The first win I would be looking for is getting the submakefile calling the rust build process.

Hi,

For info, attached a cleaned up makefile that compiles the core of lcnc. Maybe it helps a bit.

Just a small update: I've cobbled together an MPG input using a 7i77 I had lying around, an old used Siemens MPG and this luxurious cardboard box.


It's meant for testing of the planner, and sure enough, I immediately found a bug that I'm now working on ironing out. I've managed to create a test that repeats it and identified where things go wrong - now I just need to figure out how to fix it...

---

No real progress on build integration yet, but I have an idea on how to do that now at least.