scurve trajectory planner

Wild guess, as I haven't looked at all, but it may be related to the compensation logic (used for backlash etc) - as I remember it's hard coded to allow 200% accels to fix position errors and is used for example for backlash and mapping and could cause such behaviors if it is involved in some way.

Get same results when calculating vel for joint.0 inside the planner. Havent figured it out yet. I thought maybe split cycle. But have to dive deeper into it. Will do a motion test tomorrow.

In this example no scurve is active. The traject position is incremented 0.01mm each cycle.

The spikes are caused by bspline interpolation.
Even when the bspline has a high resolution like 1000 points. It wont change.
So maybe change it to a linestrip. and then interpolate the linestrip. See what happens.

 

Hi,

The spikes are solved. Problem was found. Not havely tested, just one video.
1. Using a linestrip derived from a bspline seems to work ok.
2. Slightly changed the scurve algo.


Code is updated.

@Hmnijp,

I can provide all the programs I used for the comparison, maybe it will help to fix the errors. 
Yes indeed.
Please provide the programs.

To be reviewed, fixed:
 

I really like this example:
 

Hi Grotius. I can also provide a non functional code. Works as it should with the standard tp with 2.9.3.

With scurve tp it jumps all over the place. 9axis sim machine or a self configured machine is no difference. Also your given 3axis mm machine with a added 4 axis is the same.

 

@Julian,

Thanks for the interesting file.

The first problem is solved :
1. Buffer overflow.
-> cause :  tcqFull() function was not used.
-> solution : tcqFull() function now uses a max buffer size to prevent buffer overflow. Default = 1000.

The second problem is not solved today:
2. It run's up to ca 1000 lines. Then it hang's.
-> cause : tiny segment length's : 0.007mm.
-> solution : review, recode the abc, uvw part of the planner step by step.


 

Joco wrote:

Don’t make that assumption re feedhold. And tapping. The planner is taking things direct from the Hal pin. Not from the lcnc motmod module.

it needs to be explicitly tested. Unless someone has done so already and can confirm what the behaviour is. 
 

I can confirm that LCNC 2.10 disables feed-hold while synchronized motion is in progress.  FH has no effect during a G33 or G33.1 command until after the synch move is complete.

@Grotius

Glad I can help. Yes, the code is stupid fine detailed. So for me it is a benchmark (standard tp has trouble to keep the speed, your tp is in generell faster) and not a "normal" everyday nc code. I have the code with different segment length, but the longer ones also hangs up after a while.

I played a little with the cycle time of axis. There is something going on, but I didnt get it. Maybe after you finished your steps we can go into the topic cycle time? I saw that you use a way shorter time than default. But maybe it is just a unknowledge on my side.

spumco wrote:

Joco wrote:

Don’t make that assumption re feedhold. And tapping. The planner is taking things direct from the Hal pin. Not from the lcnc motmod module.

it needs to be explicitly tested. Unless someone has done so already and can confirm what the behaviour is. 
 

I can confirm that LCNC 2.10 disables feed-hold while synchronized motion is in progress.  FH has no effect during a G33 or G33.1 command until after the synch move is complete.
 

And that behaviour continues under scurve planner?  That was what I was referring to. Not what standard planner does.