LinuxCNC S-Curve Accelerations

Hi Rod,

I don't see the code yet following this template.
It's exaclty following this template. This was the easy part.

I followed the template. Using the tpcomp.comp as starting point was going ok.
Mr garret's comments where perfect starting point. In no time the app was running.
It took me less then one hour.

But then the comments falls back to replacing the original tp.c file to your custom_tp.c file.
Then you are on your own...

The tp.c file is around 3000 lines. Quite a difficult point to start?

The idea was and is to minimalize the tp.c file. So that there is a clear understanding of the program flow.
At the moment i have some insights. But at some points i am missing something.





 

For the one's who are interested, parts of the scurve lib is already brought to c component style.

It already run's in a component. Exciting, the first part is almost finished.

I had to dive into writing c again.

scurve_c

Hi,

The question is no longer a question.

I added a parameter of type bit for testing.

When this param is set to "true"
it pops a gcode line of the queue.

So for now i will try to keep the queue code intact.
There is still a lot to figur out.

This is good news.

in tcq.c there is a funny text :

Ok then.

   

The idea is to expand the parameter list with relevant tp.c stuff.
Then we can get a nice impression what is going on.

I get more and more the idea i could directly test some scurve's
without modifiying a lot of code.

 

Great stuff.

Just a heads up in /src/emc/motion/motion.c and associated files, there are some debug pins that are designed for developers dealing with this sort of stuff to debug work using halshow. Basically, you just publish the data you are looking at to a hal pin. You might need them yet.

Hi,

Yes Rod, it's handyer to create hal pins or params to debug.

Yesterday and today i finished the scurve component conversion from c++ to c.

I have a question related to the c code of the component.

In one function (a big function) i am a little confused about using free memory and clear a vector.

line 1421 if i free the memory and do a vector cleanup. The component will do nothing the second curve request.
The timer of the component will stay to run.

At the moment it's outcommented, the component will run repeatedly without any problems, but
i did not take care of free memory. Is this a problem?

A video the component running in axis, with halsope :
link to github video

The video looks oke to me. Its 2 channels, so the acc curve it only shown as value in the left.

For the rest of the day, i now will go on with the tc.c file, adding more debug params.
And will try to look at the velocity profile that is used.

 

free() just marks the memory as "free" but doesn't actually clean it. Don't use pointer after free()ing it, that is illegal, will lead to memory corruption and hard to track bugs.

@rmu,

Thanks.
The component was running for 1.5 hours without any problem.

I started again working at the tp.c file.
At now finally is was able to control the tp. "Hacked +1".
But far from where i want to go with the code.

The way i made control is every cycle just add 0.002mm to the progress.
The progress (is actual line or arc lenght seen from start to current tp).
The progress value can also be a negative. So i have added little function for that to solve.
If we are close to the target, just go to the next gcode line.

This avoid's the so called "split cycle". Wich i previously called a "stitch".
The split cycle ensures exact endpoint reach in the next cycle.
The split cycle time can be a time like : 0.00035 sec to reach endpoint. Normally
the increment time is 0.001 sec, this can cause a displacement overshoot.

The control code:
As a result lcnc gives a velocity output of : 0
This is perfect. It just moves the tp trough the program at a fixed increment value for each cycle.
The tc->remove is reset after call by excisting code.

Video how the program behaves:
video link

For every video i have directory in source code including the c source.

link to source code

In theory i could just put a scurve inside now. Who would preferr this?  Just a raw test now?

Vote please !!


 

I think in real time linuxcnc, you are supposed to use hal_malloc instead of malloc. You might check that out.

If you allocate memory  with malloc, you the programmer must manage it. If you do not free it, a memory leak will ocurr and eventually, a memory overrun will ocurr and bad things happpen. here is why

When a program is compiled the code is written starting at the base of memory lets say at memory location 0x0000
Global (static) variables are created in what is called the heap starting at 0xFFFF in our super simple example and growing down.
Malloc allso allocates memory in the heap growing it down.

The stack starts at the top of the code and grows up. When a procedure is called, the memory for its variables are created in the stack. When the procedure is exited, the stack memory allocated to it is freed automatically.

So if you use malloc in a procedure and never free the memory before exiting, the next call to malloc of the same variable will mean that a new section of the heap is allocated (growing down). If the heap grows far enough, it can overwrite the stack (growing up) and that is when really bad unpredictable behaviour happens. This is because when you read a  malloced variable, it might have been overwritten by the stack. Likewise, you might call a procedure and executable code is overwritten by a call to malloc. it is your responsibility to manage memory allocation and deallocation!

In higher level languages, this memory management is maybe done for you.

Memory leaks may not be an issue in architecture where memory abounds, but  say you are programming a 64k 8088 device it is vital. Another example might be on an Arduino which might only have a 2k global memory space for variables and text.

Hope that helps.

rodw wrote:

[...]
So the rule is for every call to malloc, you must also have a corresponding call to free BEFORE you exit the same procedure or you are setting yourself up for failure and you will spend days chasing random code errors due to memory overflow...

Hope that helps.

I'm sorry to say that, but that is not sound programming advice. Freeing dynamically allocated memory before exiting the procedure where you allocated it completely defeats the purpose of dynamic memory allocations.