TRAJ_SET_ACCELERATION not possible via NML ?

Recently I've been experimenting with NML, with the eventual goal of making a server that would allow interaction with OpenPNP. One of the requirements is that trajectory acceleration can be changed between movements, so that very small and light components can be placed as fast as the machine can move, but for larger components the acceleration will be reduced so they don't fall off the vacuum nozzle.

To do this I tried using the EMC_TRAJ_SET_ACCELERATION message, but looking at the source I can't see any way this message can ever be executed.

When the task state is OFF, ESTOP or ESTOP_RESET, I get this result:

    command (EMC_TRAJ_SET_ACCELERATION) cannot be executed until the machine is out of E-stop and turned on
    
This is because the set acceleration message is not handled in the switch/case here:

    github.com/LinuxCNC/linuxcnc/blob/master...askmain.cc#L788-L800


When the task state is ON, the set acceleration case is again not included in the command types that can be executed:

    github.com/LinuxCNC/linuxcnc/blob/master...askmain.cc#L890-L895

...which leads to these results, depending on task mode:
    
    can't do that (EMC_TRAJ_SET_ACCELERATION:208) in manual mode
    can't do that (EMC_TRAJ_SET_ACCELERATION:208) in MDI mode
    can't do that (EMC_TRAJ_SET_ACCELERATION) in auto mode with the interpreter idle


As far as I can tell there is no combination of state and mode in which the set acceleration message will be permitted. The only place TRAJ_SET_ACCELERATION does actually appear is in the preconditions check, where it requires the state WAITING_FOR_IO.

    github.com/LinuxCNC/linuxcnc/blob/master...kmain.cc#L1515-L1525

If I understand that correctly it just means the acceleration cannot be changed in the middle of an already ongoing move, which kinda makes sense. So I'm wondering if this is all correct and as intended, or if maybe some cases were not added where they should be and it just went unnoticed? After all, this is probably not a common requirement in the milling and turning world...
 

I'm the one that's been pestering the openPnP group about this. While the Gcode server thing isn't hugely popular in LinuxCNC, a more compliant one would probably go a long way for somebody looking to run a 3D printer on LinuxCNC, and obviously OpenPnP.

The effort is much appreciated.

I tried adding the required cases and rebuilding. The EMC_TRAJ_SET_ACCELERATION and EMC_TRAJ_SET_MAX_ACCELERATION messages are now accepted without error but they have no effect. Acceleration behavior does not change.

I also discovered that none of the regular methods of setting these values work either. For example, even when [TRAJ]DEFAULT_ACCELERATION and [TRAJ
]MAX_ACCELERATION are set in the .ini file, their value in the HAL configuration shows 1e+99 which looks like the maximum value of a double, probably a default value indicating the .ini file was ignored. When I use commands like "setp ini.traj_max_acceleration 123" to change them, this is also accepted without error and the values shown in HAL configuration change, but again there is no effect on acceleration behavior.

Setting the max acceleration for an individual axis (eg. "setp ini.x.max_acceleration 123") works fine, it's just the 'traj' as a whole that has no effect.

According to these docs, I understand it should also be possible to set the 'traj' value:
    linuxcnc.org/docs/2.7/html/config/ini-config.html#_traj_section
    linuxcnc.org/docs/html/man/man1/milltask.1.html

Note that in that first page, for DEFAULT_ACCELERATION it says "in machines with nontrivial kinematics, the acceleration used for "teleop" (Cartesian space) jogs", and my machine uses trivkins which I think means this does not apply. However for MAX_ACCELERATION it simply says "the maximum acceleration for any axis or coordinated axis move". Perhaps this is also only applicable to nontrivial kinematics setups, and it's just not mentioned.

Anyway, now I'm completely stumped about how to set the trajectory acceleration at all, let alone via NML ! 

Regarding the original goal, a workaround would be to set the max acceleration of each individual axis to a slightly smaller value than the actual allowable coordinated acceleration, and just accept that the machine will be somewhat crippled by only being able to move at 1/sqrt(2) of the speed it was lovingly constructed to achieve... fortunately large components are not that numerous so overall it's not a big loss. This can be done as documented here: 
    www.linuxcnc.org/docs/html/gcode/m-code.html#mcode:m100-m199

Even that is not without problems though because when my M-code script is used in a program they only work the first time. After that the program just runs with the full acceleration value as in the .ini file

I wouldn't be surprised if [TRAJ] MAX_ACCELERATION was dead since the new trajectory planner was donated in 2.7 (?). I haven't seen it in a long time, not even the sample configs. I do have it in one of my configs that's been migrated from probably before the new TP was added. Per axis acceleration doesn't appear to exist as an NML command

I think the new trajectory planner considers the axis with the highest max acceleration as the global max acceleration during coordinated moves.

Even that is not without problems though because when my M-code script is used in a program they only work the first time. After that the program just runs with the full acceleration value as in the .ini file

Is that a limitation with your script? I don't see why ini.n.max_acceleration would set itself back to the original value. The ini pins that I have used in other configs persist until LinuxCNC is restarted obviously.

I got a little caught up in overthinking the M204 thing myself, probably because I don't know exactly how it's used in OpenPnP. Realistically it's not too tough to implement it in the hal file. You can have your normal max values set in the ini and then secondary static acceleration values can be switched to just based on something like a vacuum pump or solenoid turning on with the mux component. If you need to mimic the M204 style acceleration values being passed over Gcode, then the user Mcode file would just set the mux input pins with the Mcode and the output of the mux would obviously be connected to the  ini.n.max_acceleration pin

You'd have to use a mux for each axis which isn't a huge deal but a dedicated hal component could be written to basically do the same thing and be a bit more specific.

Or is this something that is more complicated than that?

My M-code script is like this (file name M171):

    #!/bin/bash
    acceleration=$1
    halcmd setp ini.x.max_acceleration $acceleration
    halcmd setp ini.y.max_acceleration $acceleration
    halcmd setp ini.z.max_acceleration $acceleration
    exit 0

My test program just makes a handful of simple moves and sets the acceleration between them each time (eg. M171 P10). When I load and run it as a program in auto mode, it usually results in the acceleration for every move being whatever the final setting in the program is. I suspect that in auto mode some kind of look-ahead is being done that applies the new acceleration setting before the movements it relates to are actually performed. The exception to this is when it's the first time the program is running after being loaded, and I loaded it using my gcode server commands, so the Axis GUI doesn't know anything about it. In that case some of the acceleration settings are actually applied in auto mode.

On the bright side, when I take the exact same program gcode and paste it into my telnet/gcodeserver the accelerations all work as expected. Strangely this is still ok even when I paste the entire program in and LinuxCNC accepts all the commands up front while the first movement has barely started. When given as MDI commands, it seems like they can still be queued but without any kind of look-ahead or batch processing fanciness.

btw where the max_acceleration of axes differs, it uses the individual setting for each, rather than treating the highest axis setting as the global maximum. So for example reducing ini.x.max_acceleration has no effect on a movement that only moves in Y and Z.

For the purposes of OpenPNP where gcodeserver/MDI commands were the desired control method anyway, I think this will be fine. The majority of components are tiny passives where the machine can run at full acceleration, and the (fortunately less numerous) larger components will just be placed at a slightly less than optimal acceleration.

Implementation-wise, we can just tell OpenPNP to use whatever M-code the script file is called and that's it. After all this, my gcode server will not need to do anything special to handle acceleration changes.
 

Well I look forward to using it when I get everything else sorted out. I'm sure there can be some tweaks made down the line.

I think the new trajectory planner considers the axis with the highest max acceleration as the global max acceleration during coordinated moves.

I'm not sure this is correct. Accelleration is a question of physics of your machine. Its designed to be put in the ini file and forgotten about for a particular joint. As far as I know, The TP respects the individual joint accelleration... They can be different, but when I had axes with different capabilities, I went for the lowest common denominator. Note a diagonal 2D move can exceed the individual axes limits beacause of said physics because both axes are contributing to the move...

OK Couple of things here. iforce2d, the doc you linked to is from 2.7. The 2.8 doc changes [TRAJ] MAX_ACCELERATION to [TRAJ] MAX_LINEAR_ACCELERATION.
linuxcnc.org/docs/stable/html/config/ini...g.html#_traj_section
No idea what that does to the NML channel

I fired up a VM and played with the Axis sim.  I don't know if the ini accepts the former or not but in the ini but the only pin exported to hal is the ini.traj_max_acceleration pin and only on the undefined C axis. It does indeed follow the [TRAJ] MAX_LINEAR_ACCELERATION setting. I noticed pretty much what you noticed in when playing with the pin, it doesn't seem to do anything, however since it showed up on the C axis for no apparent reason I think it only serves to set unset axes. A and B axis do have normal pins exported but they must be referred to the kinstype or some other method of setting defaults to make the TP happy.

rodw wrote:

I think the new trajectory planner considers the axis with the highest max acceleration as the global max acceleration during coordinated moves.
I'm not sure this is correct. Accelleration is a question of physics of your machine. Its designed to be put in the ini file and forgotten about for a particular joint. As far as I know, The TP respects the individual joint accelleration... They can be different, but when I had axes with different capabilities, I went for the lowest common denominator. Note a diagonal 2D move can exceed the individual axes limits beacause of said physics because both axes are contributing to the move...

Individual axis accelerations have always been in LinuxCNC but the [TRAJ] MAX_ACCELERATION had to do something right? In the old docs it is explained asI won't claim to be a Trajectory or Kinematics expert but while I was messing with the axis sim it certainly seemed to support what I said rather than what you said except it's based on lowest axis acceleration, not highest. And for clarity's sake I meant that the axis with the highest max accel was the TP's global max accel for the axis involved in that coordinated move. The TP may consider the unused axis max accel for lookahead but that's kind of besides the point I was making. While testing I found that all joints are actually limited to the lowest transformed acceleration

if ini.0.max_acceleration is 100 and ini.x.max_acceleration is 100 than it's kind of a moot point. Hovever if ini.x.max_acceleration is 2 than the joint is limited to the transformed ini.x.max_acceleration. You can verify that by looking at the output pin joint.0.acc-cmd which is described as:
So the TP is definitely looking at the axis max acceleration OR the joint only after it's been transformed. In actual use I find [JOINT] MAX_ACCELERATION/ini.1.max_acceleration to do absolutely nothing with trivkins, it's all based on the axis transformed joint which appears to be axis*0.5=Tjoint

Note a diagonal 2D move can exceed the individual axes limits beacause of said physics because both axes are contributing to the move. 

Nope.
For teleop jogging which is joint jogging is cartesian space from the way I understand it, yes the joint accel can exceed axis accel but that's not what we're talking about here, and it does not do that in MDI mode which uses the TP. Oddly enough joint accel seems to be ignored for teleop jogging as well. Teleop jogging comes down strictly to hardware acceleration limits best I can tell.

for G0 Xn Yn moves the acceleration is always limited to the lowest axis max_acceleration with the axis with the shortest distance to travel not exceeding some fraction of that limit. As far as the "Accelleration is a question of physics of your machine"....Well, yeahhh but we're talking about how the trajectory planner is affecting acceleration and specifically why the NML channel has no effect, not how or why you set it to what you set it to. You have to refer to the original question.

Everything I'm saying here is based on sim.axis so unless something is setup wrong in that sim than this is what I see.

tommylight wrote:

Pretty sure there was the possibility of setting the lookahead somewhere, also using old TP.
No idea where or how, getting old and senile!
 

It's the [TRAJ] ARC_BLEND values. It refers to look ahead being measured in "segments". I suppose the question is "in what cases does MDI/AUTO accept more than one segment at a time?" The Axis UI MDI just queues up segments when multiple lines are presented, it doesn't feed multiple segments. It sounds like pushing multiple lines through a server implementation at least in some cases can accept multiple segments based on what iforce2d said and the fact that linuxcncrsh allows AUTO mode which is only described as when you feed a gcode file.