It appears that an M67 used before the last motion line before a queue buster, itself becomes a queue buster.
I can put multiple M67 commands in between line segments, and the M67 before the last segment will cause a dip in velocity if the command after the line segment is a queue buster. I've attached sample code, and here is a link to a halscope trace of the velocity while running this code: http://pasteboard.co/Aqcny3w.png
If you take out the M5, the top velocity dip vanishes. It also seems that the longer that last line segment is, the smaller the velocity dip. Change line 17 from X5.500 to X6.500 and the top velocity dip in halscope will be much smaller.
I tested with M62/M63 and it exhibits the same behavior. After some discussion on IRC it appears this may be a fundamental flaw in the way the last segment of motion is handled in linuxcnc, and these codes just cause that to show up?
running with the naive cam detection turned off (G64 Pn Q0) or having movements with an axis other than XYZ will also cause a simular dip in velocity at the last segment.
http://linuxcnc.org/index.php/english/forum/20-g-code/29662-coordinated-motion-involving-rotary-axis?limitstart=0
Last edit: Todd Zuercher 2015-10-01