Major performance problem

spw

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.

spw

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.

T3P3Tony

@spw thanks for the report. Are you able to downgrade to 1.21 for now. @dc42 will need to look into this further when he is back from holiday.

spw

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.

3DPMicro

T3P3Tony,
Sorry to see folks with issues they anxiously want resolved but glad to see dc42 is taking a well deserved rest.

dc42

Please remind me of this issue when I return.

spw

@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

dc42

I think I can see the problem. When commands such as M3 and M5 are interspersed with movement GCodes, the movement GCodes go into one queue and the other commands go into another with a maximum length of 8. I think that second queue is getting full. That is likely to happen if you have more than 8 M3 and M5 commands within a time of 2 seconds + one move. At the slower speed each dashed line takes two seconds and you have 6 M3/M5 commands, so the queue doesn't overflow. At the higher speed, there are about 12 M3/M5 commands within 2 seconds, so it does.

In firmware 2.02 I already plan to rewrite the code to pass critical commands such as M3 and M5 in the movement queue, and at the same time allow laser cutters/engravers to use a parameter on the G1 command to control the laser. For version 2.01 I will see whether it is possible to suspend the processing of new moves while the secondary queue is full.

Catalin_RO

@dc42 My two cents on the problem... What if G0 is with laser off and G1, G2 and G3 are with laser on? In the end that is the original meaning of the commands: G0 for quick move between machining points and G1/G2/G3 for movement when actually machining!

spw

This post is deleted!

spw

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

I don't think suspending adding moves to the queue would be risky, because this will only happen when there is a M3 or M5 command pending that can't be queued. I already implemented this yesterday.

Support for using the S parameter to control laser power on G1 moves will be added in firmware 2.02.