Change acceleration while linuxcnc is running?

I am experimenting with M67 for interfacing with an analog signal to drive a laser for raster and see that I have a very slow feedrate.
Searching I found others with the same problem and realized that the main reason is low acceleration, so I changed the acceleration in a sim configuration and saw that the feedrate goes up as I increase the acceleration.

Is there any way to alter the acceleration value while the program is running (for example with a custom M code) so that I can improve the program's performance?

Not being fully aware of your problem, have you also looked into the new trajectory planner? It might also help with feed rate problems, if they are look ahead related.
linuxcnc.org/index.php/english/forum/10-...stersprograms-wanted

Andy it is indeed not the solution, more of an experimentation thought that did not seem right to me also. It was also interesting to know if there is an option of on the fly changing of acceleration, for first time tuning machines maybe.

Todd I saw the new trajectory planner thread right after posting this one! Very interesting, kept me up till 2.30am and I couldn't wake up this morning

Tested with 2.6.0~pre in simulation at work and it works excellent! Can't wait to test at the real machine now

If you are running code that consists of many segments to approximate a shape you will definitely love it!

I'm loving it already! Actually the test is a matrix of very small line segments that make a rectangle with varying analog output.

somthing like this

and so on ..

The speed difference is about 20:1, with 2.5.4 max feedrate was a little above 300mm/min while with the new planner the feedrate goes up to my max 6000mm/min. I will test with my machine and post the results at the new trajectory planner thread. Amazing!

Weird?
I always thought M-codes like M64, M67, M68, etc. were queue busters, and in that case the new TP would not help. But maybe that is only valid for the non-motion-syncronised M-odes?

Wouldn't recycling one of the axes (Z for example, if possible) as 'laser power' be a better idea? Then the motion planner can also interpolate the laser power.

DaBit wrote:

Weird?
I always thought M-codes like M64, M67, M68, etc. were queue busters, and in that case the new TP would not help. But maybe that is only valid for the non-motion-syncronised M-odes?

Well, I don't know much about the internals, so I also think that's the reason M67 is not a queuebuster. I will test with M68 to see if there is any difference.

I also tested with higher feedrates (for a fictional machine I will build some time in the future with about 60000mm/min or so ), but there seems to be another limit there, because I had to also raise the acceleration to big values for the planner to follow beyond the 6000mm/min I mentioned earlier.

DaBit wrote:

Wouldn't recycling one of the axes (Z for example, if possible) as 'laser power' be a better idea? Then the motion planner can also interpolate the laser power.

I don't understand why Z would be better than M67 in this kind of application. I also need Z for focusing, to say the least. On the other hand, I plan to have both a spindle and a laser in the same Z head, so that I will be able to make lasered engravings.

There are some practical higher end limits to what the new planner can do for you. They are briefly mentioned in the other thread. I didn't devote enough thought to fully comprehend it. Something to do with the interaction of the servo period time length, the number of lines necessary to calculate the path, and acceleration rates creates a practical upper boundary to what is possible.

It might help to use the Z axis as your power control as Andy mentioned, this will give you the ability to have the numbers interpolated during moves possibly allowing you to reduce your line count. You said you still wanted Z for focus, I would suggest using W for that instead. The reason I suggest this way around is to get around the fact that only XYZ are currently included in the new TP. If you add a movement in another axis it reverts to the old plan. (G64s Q also is ineffective on movements including any axis other than XYZ in the old planner as well). I am told this is on the list of things to work on with the new TP, I am patiently waiting and hoping someone gets to it. I work with several XYZW machines that would benefit.