GCode parsing performance or something else?

Running LinuxCNC 2.9.0-pre0 on an rPi4 I'm seeing significant motion speed degradation when various GCode parsing methods are employed related to either spindle speed changes or analog out/M67 changes.

With this header and no spindle settings but M3/on the linear motion appears to run at or close to the desired 200mm/s.

G64 P0.010 Q0.015 ; Path Blending to help fix rounded corners
G4 P0 S0
G00 G17 G40 G21 G54
G90
M3
; Image @ 200 mm/sec, 20% power
G0X118.38Y97.2
G91
G1X-5F12000
G1X-0.1
...

With the same header and M67 commands the linear motion runs no where near to the desired 200mm/s.
And that speed varies depending on spaces within the GCode.

I just tried removing any spaces from the GCode lines and performance got even worst.
G1X-0.1M67 E0 Q45.579 becomes G1X-0.1M67E0Q45.579

Then I tried all spaces:
G1X-0.1M67 E0 Q45.579 becomes G1X-0.1 M67 E0 Q45.579
The motion performance was better than no spaces but worst than the original I'd started with were there was no space between X movment and M67 command but spaces for M67 parameters.
G1X-0.1M67 E0 Q45.579

I even tried adding G4 P0 and G4 P0 S0 to the preamble and saw no noticeable change in performance. And this shows up with or without hardware enabled, there are no encoders and the machine is only doing X and Y motion with a pin doing PWM from the M67 analog-out signal but even commenting out the analog-out => hardware pin in the hal has no effect on motion performance so can this be a problem with the parser or is there something other than G4/dwell at play?

andypugh wrote:

I think that M67 is a queue-buster, there is no blending through it.

I've seen attempts to use LinuxCNC for raster engraving for over 10 years without a decent solution because
spindle control, the common mechanism used in CAM tools for laser engraving GCode generation, induces wait cycles or something which limits performance. Some have used a faked Z axis but that influences motion in blending. Do you have any thoughts on how to get 300mm/S motion, mostly in one axis, while also getting PWM laser commands to the hardware at 254DPI?

CAM software will generate GCode either setting spindle speed using the M3,M4,M5 and Sxxxx codes:
M3 ; spindle on
G91
X-0.1S200
X-0.1S150
...

and using M106
M3 ; spindle on
G91
X-0.1
M106 S200
X-0.1
M106 S150
....

With Remora, and probably Mesa, there's a hardware PWM generator associated to a pin which is used to set the PWM to 0 or some percentage(0-100) for the pulse width. ie spindle.0.spindle-speed => remora.SP.0
The only thing I've seen so far not bust the blending queue is the A axis.

I'm not against creating a unique solution but one of my primary goals is not only use LinuxCNC for my 3 machine types(CNC, 3D printer and laser cutter) but also show others it's not only a powerful solution but also makes for easy workflows. I'm personally willing to scp files around and run pre-processing scripts on GCode but adding steps to work flows turns off new users. Making things better and faster can bring people to the platform.

Currently the laser engraving CAM tools generate gcode with spindle speed settings per pixel(XY movement) as either Sxxxx or M106 Sxxxx.

One "solution" for LinuxCNC doing engraving was a standalone tool which too in an image, generated scanning the machine tool back and forth across the image area and also generated a file containing the laser power levels which got streamed to the hal via a realtime process. A nice solution but won't fit into the laser CAM tools workflow people are already used to. ie LightBurn, LaserWeb, bCNC, etc.

But if the GCode from these CAM tools could generate the needed data/data structures when the GCode file was loaded... there would be no workflow change experience by the operator. But would also have to support more than square or rectangle images and support scanning across any direction and not just X or Y scans.

These files are often quite large too so maybe maybe storing the generated streaming data and checking for its existence on the next load would would at least mean reloading/rerunning the project would have a much quicker startup time.

My machine is out of commission until new stepper motor bearings arrive and I rebuild the motors and recalibrate the machine so I can't do any testing on the machine. simulation is still an option and I will relook at that realtime streaming option when I find it again.

What the data painter is intended to do is phase lock (position lock)
a data stream (binary or PWM values) to set of position waypoints.
It would likely require some interpreter modifications to include
a data stream for the video and including start/stop stream markers.
It probably also requires the hal_port data type to feed the FIFO

So I'm giving M67 and M68 a try but I was thinking I need to invert my PWM since with only 15% power it's etching through the 3mm plywood.

I could not figure out how to invert the signal so I put the original board running Smoothieware on the bench and looked at the FET output with a 4.7K pullup to 5V. It was showing a dominant high signal with short drops to 0v looking like the 15% power setting.

I then powered up LinuxCNC/Remora and saw basically the same thing.

so something is not the same. My though on continuing this journey is that dithering might still be reasonably fast on LinuxCNC even if the movements are at 254 DPI, ie .1mm moves for each pixel dot. I tried so many variations and currently have M67/M68 wired up so trying to get that working for the time being.

M67/M68 slow the motion down too much. So much that even 5% power level burns deep into the 3mm plywood.

I tried a fill region, 75mm x 50mm with requested speed of 200mm/s and while I doubt it was giving 200mm/s, it was fast enough that 5% power made a lighter turn than 15% and 25%. The tests gave me hope 5% power setting would product some form of dithered engraving but with the motion slowed down so much, it was looking more like just a deep burned line instead of a surface engraving.