Posts made by spw

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

I did some testing and while the hardware and implementation would point that Duet should be faster the tests show otherwise.
My results:
Firmware 2.0.2
300 DPI raster @ 200mm/s UI was showing max top speed 30mm/s out off requested 200mm/s
100 DPI raster @ 200mm/s UI was showing max top speed 67mm/s movement was visibly faster
Firmware 2.0.4
100 DPI raster @ 200mm/s UI was showing max top speed 81mm/s

The last job had 16k G1 moves and completed in 60 seconds which means Duet can process about 267 gCodes/second which is 10 times less than Cohesion3D.

Can anyone familiar with the firmware ( @dc42 ) confirm that my results make sense or I should be looking into configuration/gCode problems?

My setup is Ender-3 theoretically able to deliver movements of 220mm/s and configured like that (M203 X12000 Y12000 Z900 E3000 ).
The test was executed using web UI to upload and start the job.
My files:
config.g
duet.gcode
LASER MODE macro.g

Is there any benchmark that shows how many gcode/second can Duet 2 process?

I have a Duet in my 3D printer and love it, used it with a blue laser and did well. Now I'm planning to use it with K40 CO2 laser cutter, but it looks like everyone is using Cohesion3D https://forum.cohesion3d.com/t/improved-raster-speed-firmware-update-for-cohesion3d-boards/850 .
The CO2 laser raster printing can be done much faster than blue laser which makes me worry that Duet won't be able to support it.

@dc42 great work on adding S parameter to control laser PWM
I have a suggestion to make it more compatible with other laser engravers and Laserweb software:
When S parameter is not provided it should keep the previous PWM value instead of turning off the laser, the G0 should turn off the laser
Example output from Laserweb:

G0 X86.61 Y21.34
G1 X86.61 Y21.34 S255.00 F1300
G1 X86.61 Y21.33
G1 X86.62 Y21.33
G1 X86.62 Y21.33
G1 X86.62 Y21.33
G1 X86.62 Y21.33

G0 X91.07 Y16.73
G1 X91.07 Y16.73 S255.00 F1300
G1 X91.07 Y16.73
G1 X91.07 Y16.73
G1 X91.06 Y16.73
G1 X91.06 Y16.73
G1 X91.06 Y16.72
G1 X91.06 Y16.72

@dc42 said in New firmware 2.01 beta 2 available:

Non-movement commands were not correctly synchronised with movement commands when there were more than 8 non-movement commands interspersed with more than 2 seconds of movement

Laser engraving works correctly now, thank you.

Suspending move when the queue is full would be risky as if it happened when the laser was enabled at the full power it would burn a hole or even start a fire is set in one place for too long.
Adding PWM parameter to G1 command would be ideal as this is what Laserweb generates by default. M3 and M5 are used in Marlin compatibility mode.

@dc42 said in Major performance problem:

Please remind me of this issue when I return.

reminding, let me know if you need more logs or setup code

In 1.21 there is an additional bug that merges the second line at speed 300 although it does turn off the laser before switching to speed 700. Like in 2.0 first 2 segments at the higher speed are missing.

Log after G1 F700

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01beta1(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-95BNL-MGPSN-6J1F4-3SD6J-KJX7X
Used output buffers: 3 of 20 (18 max)
=== RTOS ===
Static ram: 28452
Dynamic ram: 96004 of which 0 recycled
Exception stack ram used: 372
Never used ram: 6244
Tasks: NETWORK(ready,324) HEAT(blocked,1256) MAIN(running,3572)
Mutexes: FilamentSensors(null) DHT(null) WiFi(null) TelnetGCodeReply(null) HttpGCodeReply(null) Telnet(null) HTTP(null) SD1(null) SD0(null) DirSearch(null) FileSystem(null) Aux(null) USB(null) MessageBox(null) ToolList(null) SPI(null) Malloc(null) NetworkGCodeInput(null) NetworkGCodeInput(null) FileInfoParser(null)
=== Platform ===
Last reset 01:47:29 ago, cause: power up
Last software reset at 2018-06-26 00:04, reason: User, spinning module GCodes, available RAM 6236 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 38.6, current 38.7, max 38.9
Supply voltage: min 23.9, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: ok, SG min/max not available
Driver 2: open-load-B, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-06-26 20:41:59
Slowest loop: 180.78ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 218, MinFreeDm 216, MaxWait: 9682ms, Underruns: 0, 0
Scheduled moves: 23, completed moves: 12
Bed compensation in use: 4 point
Bed probe heights: -0.613 0.097 0.732 0.675 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "M5" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is not empty:
Queued 'M5' for move 16
Queued 'M3 S255' for move 17
Queued 'M5' for move 18
Queued 'M3 S255' for move 19
Queued 'M5' for move 20
Queued 'M3 S255' for move 21
Queued 'M5' for move 22
Queued 'M3 S255' for move 23
8 of 8 codes have been queued.

Hi,
The latest 2.0 firmwares have a major performance problem when used with M3, M5 commands.

The following code should use a laser to engrave 2 dashed lines at speed 300 and then 2 dashed lines at speed 700.
0_1530069907756_my.gcode
Result:

So far I've tried without any luck:

• Firmwares: 2.0 RC4 and 2.01beta1
• Using regular printer mode with M42 P2 Sxxx
• Modifying speeds, motor configs, accelerations with M566, M203, M201
• Modifying PWM frequency and max value in M452

First 2 dashed lines (at speed 300) are engraved correctly then when printer moves to engrave at speed 700 for some reason it skips M5 (even it is issued before speed change) command and skips first 66% of the first line and finally prints last line correctly.

It looks like there is some kind of queue or movement prediction that is causing to skip the M3, M5 commands at higher speeds.