@Arthur_Wolf What you’re suggesting here would not be Gcode anymore. I’m not saying that’s bad, but it feels like up to this point Smoothie has tried very hard to stick to being a proper Gcode interpreter.
@Jason_Dorie We can keep the S each line that’s no big deal. Just keep G1 modal and make X0.1 modal, really.
If you were going to do it, it’d make more sense to do it this way: send a single G1 command with a payload of 1 bit or 8 bit values to use as intensities, to be stretched along that line. Then there’d be no float rounding / accumulation errors, and you’re not limited to a fixed axis. You mostly leave the planner alone, and just hang the scan data off of a pointer in the block. Point-sample the block data as you traverse the move, use that as your current S value, scale by speed as you normally would. It’d be much more efficient than assembling it from S commands.
I’ve found (empirically) that leaving out the leading zero is valid. An example G-code file on Wikipedia shows this as well, and I know I’ve seen it before, so it may be reasonably well supported.
I’ve done a bunch more testing, and made my stream speed output more granular, and it looks like I’m likely hitting the “1000 codes/sec” limit. I have the highest lines/sec output showing when I hear it bogging down - at those points it’s hitting 750 lines/sec (tested on a Mac). Since it’s an image with varying content, some of it is running full speed and some isn’t, so not hitting the full 1000 is reasonable.
Are there things that could be disabled in the config that would reduce the CPU load and improve throughput? Is there a reason the N_PRIMARY_ACTUATORS has to be 3 or more? (Is the laser PWM considered an actuator?) I was thinking of attempting a recompile with only 2 axis enabled, but saw that in the code.