Firmware 3.0beta12 was able to achieve 1300 gcode/s although I didn't update the config and the laser wasn't firing so it might go down once the config is fully migrated.

Duet2CombinedFirmware.bin

Thank you it helped a lot. I reduced *8 to *5 and it doubled free memory, now with the complex menu, I still have 4000+ bytes free.

Since the memory is dynamically allocated do you think you could add a GCode to reallocate this buffer so I don't have to recompile firmware with every version, I think other users would benefit too since 4 motors + 1 or 2 heater is the most common setup.

I'm using only 3 motors is there an easy way to free this memory, I can recompile firmware if needed.

What value I should be aiming for safe operation?

Never used ram: 76

value with smaller menu: 468
value without screen (no M918): 5968

When the menu file is over 30 lines long the board restarts when the menu is selected. Making the menu shorter by a few lines makes it stable for a little bit and crashes after a moment. Short menus < 20 seem to work fine. Maybe memory issue?

My HW:
Duet Wifi v1.03 with 3.2beta2 firmware

My config:

M918 P1 E4 F2000000

crashing menu file:

text R0 C2 F0 T"x:"
alter N510 D1 W26
text C46 T"y:"
alter N511 D1 W26
text C88 T"z:"
alter N512 D2 W32

image R12 C0 L"hline.img"

text R14 C1 F0 T"x"
button C11 T"-50 "  A"G91 G1 X-50 F6000"
button C32 T"-10 "  A"G91 G1 X-10 F6000"
button C50 T" -1 "   A"G91 G1 X-1 F6000"
button C69 T"+1 "   A"G91 G1 X1 F6000"
button C87 T"+10 "  A"G91 G1 X10 F6000"
button C108 T"+50 " A"G91 G1 X50 F6000"

text R26 C1 F0 T"y"
button C11 T"-50 "  A"G91 G1 Y-50 F6000"
button C32 T"-10 "  A"G91 G1 Y-10 F6000"
button C50 T" -1 "  A"G91 G1 Y-1 F6000"
button C69 T"+1 "   A"G91 G1 Y1 F6000"
button C87 T"+10 "  A"G91 G1 Y10 F6000"
button C108 T"+50 " A"G91 G1 Y50 F6000"

text R38 C1 F0 T"z"
button C11 T"-25 " A"G91 G1 Z-25 F6000"
button C32 T"-5 "  A"G91 G1 Z-5 F6000"
button C50 T" -1 " A"G91 G1 Z-1 F6000"
button C69 T"+1 "  A"G91 G1 Z1 F6000"
button C87 T"+5 "  A"G91 G1 Z5 F6000"
button C108 T"+25 " A"G91 G1 Z25 F6000"

image R50 C0 L"hline.img"
button R51 C0 F0 T"<" A"return"
button T" Home All " A"M98 P/sys/homeall.g"

Firmware 3.0beta12 was able to achieve 1300 gcode/s although I didn't update the config and the laser wasn't firing so it might go down once the config is fully migrated.

In topic https://forum.duet3d.com/topic/12785/duet-2-wifi-performance-for-laser-raster-printing/6 I found out that Duet 2 (v2.0.4) has a limit of about 550 gcodes/s which is about 5 times slower than Cohesion3D or default GRBL on 120MHz LPC and 2 times slower than default Smoothieware.

My understanding is that Cohesion3D firmware was modified specifically for laser engraving so that even with slower hardware it is able to process commands faster. The Cohesion3D has 2 other problems with large raster engraving gcode files that usually weight 30MB:

1. Communication is painful when speed is required - removal of the SD card to upload gcode
2. Communication is slow if done over serial as the laser firmware doesn't support any kind of networking.
   I wasn't able to find any product which would provide both fast communication and fast printing.

I would like to know 2 things:

1. Is it a major refactoring to speed things up or a couple 'if' statements to disable features that take CPU time but are not required for the raster engraving.
2. Is there a desire to make such changes to the firmware in any foreseeable future to enable support for "powerfull" CO2 lasers

If there would be any support from firmware I would create open-source adapter PCB project to provide a drop-in replacement for controllers in most popular K40-style CO2 lasers.

I played a bit with the speed and it looks like the limit is 140mm/s for 100 dpi at this speed the movements are smooth anything higher makes "Top speed" value to fluctuate and printer jerk during the long moves.

The limit of Duet is:
3.94 px / mm x 140mm/s = 551.6 gcode/s

It is about 5 times slower than Cohesion3D and 2 times slower than default Smoothieware.
I'll create a new topic in wishlist category to find out if there is any desire or even if it is possible to improve the firmware to support higher speeds.

Thanks @Phaedrux it was my mistake I didn't think about bumping acceleration and jerk.

It did help with the performance I can hit 136mm/s and the job is completed in 36 seconds which increased the throughput to 444 gcode/sec, but there was a side effect.
The gCode instructs the machine to move a laser along x-axis for 120mm and then proceed with next line. The movement is a very uneven entire machine is jerking but not on direction change but during the long movement. I tried both 2000 and 1200 jerk as well as some very high values like 20000 and 12000 with the same result.

I think it is because there is some delay between executing the commands and the x-axis motor constantly decelerates and accelerates instead of doing long streaks.
I'll play with the config and remove the laser/extruder to see if it is a mechanical limitation or a firmware problem.

Video showing jerk during long movements: https://youtu.be/ePAcdSWWiTc