Major performance problem



  • 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:
    0_1530069928780_perfBug.JPG

    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.



  • 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.


  • administrators

    @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.



  • 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.

    0_1530146648993_121.JPG



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


  • administrators

    Please remind me of this issue when I return.



  • @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


  • administrators

    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.



  • @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!



  • This post is deleted!


  • 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.


  • administrators

    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.


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.