LinuxCNC S-Curve Accelerations

it was true:

16 bit IN TRUE ini.traj_arc_blend_enable

I was running the torus gcode (from the torus.png --> image to gcode with whatever defaults)

EDIT: here's the gcode that triggered the bug:

 
 

You are right, my apologies, I was looking at it on my phone, and it formatted it intuitively. We'll be looking into it, thank you for reporting

next testing round in 3d contouring, 25k line and later are critial and we can observing high accel-cmd peaks ... I am not expert, I need to ask you guys before create any outcomes... I can chare gcode file but here it exceeding limit

Short segments seems to have some bug, might be next week for a fix...

Do you need to share the code or any assistance please?

Hello,

I've also tested several NC programs.
The jerk isn't maintained at transitions and at the end of the movement.
My configuration and the NC programs are attached.

gruß
Rüdiger

 

Share the gcode please, and we will take a look next week

He did but you probably did not get a notification as he edited the existing post.

@PCW

try with

setp ini.traj_max_jerk 3000
and
setp ini.traj_default_jerk 3000

I do not get acc violation with these values, can you confirm?

@ruediger123

at the moment jerk-cmd are debug pins, they are not to be used for machine control, because the current calculations try and do best we can to calculate and blend quickly in realtime, there are knowm spikes in the jerk-cmd, please look at vel-cmd and acc-cmd everything looks very good to me there, there are no violations there, if we were to respect jerk cmd strictly the interpolation would not be able to run as fast as it does, but we could look at making a stricter mode viable as an alternative, or possibly the default if that's what the community needs.