LinuxCNC S-Curve Accelerations

:lol: Thanks, I already got pretty much the same thing out of Sage Math. I have no idea what to do with those sqrt(<something>*i) though!

Although those types of expressions do turn up when solving cubic expressions in general, so it's probably possible to do *something* useful with it!

Edit: After a closer look it looks like WolframAlpha did find a real solution - the j's are from the input equation? If so that equation could actually be useful.

arvidb wrote: I've done some more work on this. I worked through the remaining equations and ended up with something I simply don't know how to solve. I believe it's a cubic equation

There is actually a cubic version of the quadratic formula . I don't know why schools ignore it.

Yes, as explained I had a solver for such equations from the GNU Science Library in the code, but the equation in question is not in the correct form, since it has roots of sums including the dependant variable in it. I'm not even entirely sure it is a cubic equation, but I'm guessing some math magic would turn it into one.

t2^3 = 1/6*(6*a0^2*j0*t2 - 2*a0^3 + 6*j0^2*s_target - 6*(2*j0^2*t2 - a0*j0)*v0 - 3*(2*j0^2*t2^2 - a0^2 + 2*j0*v0)*sqrt(j0^2*t2^2 - 1/2*a0^2 + j0*v0))/j0^3

Is the acceleration limit constant once LinuxCNC has started, or does it need to be modifiable on-the-run? If modifiable, is it applied immediately or only on new moves?

I'm working on integrating Smooth1d (my jerk-limited 1-axis planner) into LinuxCNC. Smooth1d has no need to remember the limits (velocity, acceleration and jerk) once a move has been planned. Simple_tp on the other hand keeps these as state, also between moves, and other parts of the code references this state. I'm trying to figure out if I should add this state to Smooth1d, just for convenience, or if it really belongs somewhere else.

Looking at motion.h there is a command EMCMOT_SET_JOINT_ACC_LIMIT. Is this used only to communicate the INI setting?

There is a field acc_limit in emcmot_joint_t, under the section "configuration info - changes rarely". Does this mean this value is in essense constant?

The only thing I've half observed is I think the acceleration is reduced when using MDI commands. I just never looked at it in detail v's the same move in gcode. It would be easy to confirm with halscope monitoring motion.current-vel for a straight line segment from the MDI and Gcode.

I think also becasue acceleration is per joint, where the segment is say at 45 degrees in the XY plane, the acceleration for the segment in the direction of the move may be above the joint limits (which are still respected).

Yeah, the reduced acceleration while jogging was discussed earlier in this thread: link .

What I'm after is if the acceleration value set in the INI file should be modifiable at a later time. Or is the value set in the INI a "machine constant"?

There are at least two arbitrary default values assigned to joint->acc_limit: in motion.c and in inijoint.cc . (They both happen to have the same value of 1.0.) Wouldn't it be better to require a setting for these obligatory limits and refuse to start if they are missing? This way there would be no risk of starting with essentially random settings, and the machine wouldn't behave differently depending on the machine units chosen.

Would it be possible to specify constant settings to motmod.so on load, as parameters, instead of via EMCMOT commands? I'm still a bit hazy on how the loading of the different modules work...