Linear moving vs M67 command

It's not a problem, perhaps a failure to understand how M67 functions.

From the Manual:

The actual change of the specified outputs will happen at the beginning of the next motion command. If there is no subsequent motion command, the queued output changes won’t happen. It’s best to always program a motion G code (G0, G1, etc) right after the M67. M67 functions the same as M62-63.

Or your not showing enough code...

John

IIRC M67 is a queue buster so even if you use G64Pn each M67 is a stopping point.

John

Kap1eC wrote:

Hi all. I have 1 problem with linear motion.
I need to change analog output synchronously with motion.

Which version of LinuxCNC?

M67 was broken previously, I am not sure when the fix went in. (However I think it just didn't work at all..)
That fix went in 10 months ago, I am not at all sure how to check which releases have it, but it certainly won't be anything prior to v2.5

It shouldn't be a queue-buster.

So much for trusting memory... M68 is a queue buster not M67.

John

Kap1eC wrote:

I have EMC 2.5. M67 and M68 gives slowdown =( Oh

Does the same code run faster without the M67 lines?

This is a regrettable consequence of a lack of lookahead in the LinuxCNC trajectory planner (And one that there is some work ongoing to fix).

The problem is that the motion controller always guarantees it can come to a halt before the end of the next move.

It might help to increase the max acceleration, unless you are already on the physical limits of the system.

G-code which intelligently splits the moves into continous moves at constant M67 values would also work better.

What is the application? I am tempted to guess that it is laser rastering?