Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Raster engrave constantly accelerating and decelerating?

    Scheduled Pinned Locked Moved Solved
    Laser Cutters
    4
    14
    537
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • bg_86undefined
      bg_86
      last edited by bg_86

      I just set up my Duet3D Duet 3 Mini 5+ on my laser engraver. First time doing any laser engraving at all. I expect with the current configuration and gcode for the machine to accelerate up to 300MM/sec in the x axis and then modulate the 5KHZ control wire to turn the laser on and off as it goes, just like a laser printer. Why does the machine accelerate and decelerate as the laser is turned on and off as it travels along? Is there a default setting that's specific to the laser mode in RRF that limits the machine feed rate during laser on G1 moves? (EX: G1 X0.085S1000) I could do some manual tests to see what's actually happening, but I am in the middle of a very long raster engrave image that is severely slowed by this. GCode and config.g are below. By the way, first time RRF user and Duet3d board owner. Best firmware and board documentation I've ever used. Coming highly recommended from me.

      ; LightBurn 1.4.00
      ; GRBL device profile, absolute coords
      ; Bounds: X2.42 Y9.98 to X217.41 Y235.39
      G00 G17 G40 G21 G54
      G90
      M4
      ; Image @ 300 mm/sec, 100% power
      M9
      G0 X2.42Y9.981
      ; Layer C00
      G91
      G1 X7.5F18000S0
      G1 X12.944S1000
      G1 X0.042S0
      G1 X0.085S1000
      G1 X0.803S0
      G1 X0.042S1000
      G1 X0.085S0
      G1 X0.085S1000
      G1 X0.042S0
      G1 X0.042S1000
      G1 X0.043S0
      G1 X0.126S1000
      
      G90                            ; send absolute coordinates...
      M83                            ; ...but relative extruder moves
      M550 P"CoreXY Laser Engraver"  ; set printer name
      M669 K1                        ; select CoreXY mode
      
      ; Network
      M552 S1                        ; enable network
      M586 P0 S1                     ; enable HTTP
      M586 P1 S1                     ; enable FTP
      M586 P2 S1                     ; enable Telnet
      
      ; Drives
      M569 P0.0 S1                   ; physical drive 0.0 goes forwards
      M569 P0.1 S1                   ; physical drive 0.1 goes forwards
      M584 X0.0 Y0.1                 ; set drive mapping
      M350 X16 Y16 I1            ; configure microstepping with interpolation
      M92 X80.00 Y80.00              ; set steps per mm
      M566 X900.00 Y900.00           ; set maximum instantaneous speed changes (mm/min)
      M203 X18000.00 Y18000.00         ; set maximum speeds (mm/min)
      M201 X5000.00 Y5000.00           ; set accelerations (mm/s^2)
      M906 X1400 Y1400 I30             ; set motor currents (mA) and motor idle factor in per cent
      M84 S30                          ; Set idle timeout
      M204 P5000 T2000                 ;Set printing acceleration and travel accelerations
      
      ; Axis Limits
      M208 X0 Y0 S1                  ; set axis minima
      M208 X304 Y304 S0              ; set axis maxima
      M564 S0 H0                     ; H0 = allow movement of axes that have not been homed S0 = allow movement outside boundaries
      
      ; Endstops
      M574 X1 S3                     ; configure sensorless endstop for low end on X
      M574 Y1 S3                     ; configure sensorless endstop for low end on Y
      
      ; Z-Probe
      ;M558 P0 H5 F120 T6000          ; disable Z probe but set dive height, probe speed and travel speed
      ;M557 X15:215 Y15:195 S20       ; define mesh grid
      
      ; Heaters
      M140 H-1                       ; disable heated bed (overrides default heater mapping)
      
      ; Fans
      M950 F0 C"out3" Q500           ; create fan 0 on pin out3 and set its frequency
      M106 P0 S1 H-1                 ; set fan 0 value. Thermostatic control is turned off
      
      ; Tools
      
      ; Custom settings are not defined
      
      M452 C"out6" R1000 S1 F5000 ; Enable Laser mode, on out6, with max intensity being 1000, sticky mode on, and a PWM frequency of 5KHZ
      
      M122
      === Diagnostics ===
      RepRapFirmware for Duet 3 Mini 5+ version 3.4.5 (2022-11-30 19:41:16) running on Duet 3 Mini5plus WiFi (standalone mode)
      Board ID: 1Y776-WN6KL-K65J0-409N2-4D02Z-7U7BL
      Used output buffers: 4 of 40 (31 max)
      === RTOS ===
      Static ram: 103652
      Dynamic ram: 109692 of which 204 recycled
      Never used RAM 26724, free system stack 110 words
      Tasks: NETWORK(notifyWait,373.0%,199) LASER(notifyWait,14.4%,38) HEAT(notifyWait,0.3%,374) Move(notifyWait,295.6%,265) CanReceiv(notifyWait,0.0%,942) CanSender(notifyWait,0.0%,336) CanClock(delaying,0.8%,333) TMC(delaying,39.5%,72) MAIN(running,195.7%,417) IDLE(ready,41.8%,30) AIN(delaying,47.9%,263), total 1009.0%
      Owned mutexes: SD0(NETWORK)
      === Platform ===
      Last reset 19:26:19 ago, cause: reset button
      Last software reset at 2023-07-14 21:53, reason: User, GCodes spinning, available RAM 26964, slot 1
      Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
      Error status: 0x00
      MCU revision 3, ADC conversions started 70167466, completed 70167465, timed out 0, errs 0
      Step timer max interval 1491
      MCU temperature: min 34.7, current 49.8, max 57.9
      Supply voltage: min 23.7, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
      Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
      Events: 0 queued, 0 completed
      Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 125, reads 7914, writes 105, timeouts 0, DMA errors 0, CC errors 0
      Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 125, reads 7914, writes 105, timeouts 0, DMA errors 0, CC errors 0
      Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 32, reads 8007, writes 12, timeouts 0, DMA errors 0, CC errors 0
      Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 29, reads 8010, writes 9, timeouts 0, DMA errors 0, CC errors 0
      Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 29, reads 8010, writes 9, timeouts 0, DMA errors 0, CC errors 0
      Driver 5: not present
      Driver 6: not present
      Date/time: 2023-07-15 17:26:02
      Cache data hit count 4294967295
      Slowest loop: 701.85ms; fastest: 0.08ms
      === Storage ===
      Free file entries: 9
      SD card 0 detected, interface speed: 22.5MBytes/sec
      SD card longest read time 7.2ms, write time 108.4ms, max retries 0
      === Move ===
      DMs created 83, segments created 60, maxWait 32001315ms, bed compensation in use: none, comp offset 0.000
      === MainDDARing ===
      Scheduled moves 19982, completed 19982, hiccups 0, stepErrors 0, LaErrors 0, Underruns [8106310, 0, 198], CDDA state -1
      === AuxDDARing ===
      Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
      === Heat ===
      Bed heaters -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
      === GCodes ===
      Segments left: 0
      Movement lock held by null
      HTTP is idle in state(s) 0
      Telnet is idle in state(s) 0
      File is idle in state(s) 0
      USB is idle in state(s) 0
      Aux is idle in state(s) 0
      Trigger is idle in state(s) 0
      Queue is idle in state(s) 0
      LCD is idle in state(s) 0
      SBC is idle in state(s) 0
      Daemon is idle in state(s) 0
      Aux2 is idle in state(s) 0
      Autopause is idle in state(s) 0
      Code queue is empty
      === CAN ===
      Messages queued 349898, received 0, lost 0, boc 0
      Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 349898/0/0
      Tx timeouts 0,0,349897,0,0,0 last cancelled message type 30 dest 127
      === Network ===
      Slowest loop: 4234.74ms; fastest: 0.00ms
      Responder states: HTTP(3) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
      HTTP sessions: 1 of 8
      = WiFi =
      Network state is active
      WiFi module is connected to access point 
      Failed messages: pending 0, notready 0, noresp 0
      WiFi firmware version 2.1beta4
      WiFi MAC address e8:68:e7:e1:4f:a1
      WiFi Vcc 3.42, reset reason Power up
      WiFi flash size 2097152, free heap 40232
      WiFi IP address 192.168.69.212
      WiFi signal strength -34dBm, mode 802.11n, reconnections 0, sleep mode modem
      Clock register 00002001
      Socket states: 3 2 0 0 0 0 0 0
      

      Perhaps because my overscan setting isn't long enough, the M204 P1500 T2000 setting is causing it to slow down accelerating before it reaches 300MM/SEC? Still, that doesn't make sense to me why it would be decelerating during a single X raster pass...

      bg_86undefined dc42undefined 2 Replies Last reply Reply Quote 0
      • dc42undefined
        dc42 administrators @bg_86
        last edited by

        @bg_86 please try increasing the movement queue length. See the PS in my previous reply.

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        bg_86undefined 2 Replies Last reply Reply Quote 1
        • bg_86undefined
          bg_86 @bg_86
          last edited by

          @bg_86 discovered gcode move clustering posts. It started off printing the first 10 seconds or so with the same issue then unexpectedly started FLYING. Still does some decelerations mid-pass but seems to average around 250 of the expected 300mm/s.
          Massive improvement. But still, why is it decelerations mid pass? I did change the print acceleration to match machine acceleration to match in case it is activated during "laser mode"

          oliofundefined o_lampeundefined 2 Replies Last reply Reply Quote 0
          • oliofundefined
            oliof @bg_86
            last edited by

            @bg_86 try adjusting minimum segment length in your kinematics definition https://docs.duet3d.com/User_manual/Reference/Gcodes#m669-set-kinematics-type-and-kinematics-parameters

            <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

            1 Reply Last reply Reply Quote 0
            • o_lampeundefined
              o_lampe @bg_86
              last edited by

              @bg_86 It might still be suffering from a too small planner buffer? I remember vaguely that the buffer could be increased via mcode, which was related to dual gcode streams. But it might help here too.

              1 Reply Last reply Reply Quote 0
              • dc42undefined
                dc42 administrators @bg_86
                last edited by dc42

                @bg_86 are you running the job from the SD card? Do you have any form of bed compensation enabled?

                PS if you need to increase the movement planner queue length, see https://docs.duet3d.com/User_manual/Reference/Gcodes#m595-set-movement-queue-length.

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                bg_86undefined 1 Reply Last reply Reply Quote 1
                • bg_86undefined
                  bg_86 @dc42
                  last edited by bg_86

                  @dc42 Yes, from an SD card. A 4GB one that meets the specs in documentation. I know we are talking about a READ issue here, but I can say that the write speed over Ethernet->Wi-Fi is ~600KB/sec. Clustered file is 80MB, non-clustered is 110MB.

                  No z axis, mesh leveling is off.

                  dc42undefined 1 Reply Last reply Reply Quote 0
                  • dc42undefined
                    dc42 administrators @bg_86
                    last edited by

                    @bg_86 please try increasing the movement queue length. See the PS in my previous reply.

                    Duet WiFi hardware designer and firmware engineer
                    Please do not ask me for Duet support via PM or email, use the forum
                    http://www.escher3d.com, https://miscsolutions.wordpress.com

                    bg_86undefined 2 Replies Last reply Reply Quote 1
                    • bg_86undefined
                      bg_86 @dc42
                      last edited by bg_86

                      @dc42 That did the trick... Sorta.I figured it was the planner queue but didn't find it in the documentation because I was calling it a "buffer" in my searching.

                      However, in the first 30 seconds of running the issue persists (with clustering gcode at least) which I could live with, however it seems to have a direct effect of how many photons are hitting a given area. The result is an area with a deeper burn before the buffer gets fully loaded and the movement is no longer bottlenecked by the planner not being big enough. Suppose it's time to clone this SD card and put everything one the one that was shipped with the unit just to remove another variable?

                      Worked my way up to M595 P100 R10000. R value doesn't seem to change anything like I thought it would. Ideally I want to front load and fill the queue before the first move takes place. I thought the r value from my interpretation of the documentation did that.

                      1am I think it's time for bed lol

                      1 Reply Last reply Reply Quote 0
                      • bg_86undefined
                        bg_86 @dc42
                        last edited by

                        @dc42 I believe I was using the provided SD card afterall. Found a random 32GB Samsung EVO card that I believe came with one of my Raspberry Pi. Massive improvement right out the gate, with jittering only occuring on the first two X direction passes (200mm across).

                        When I get done doing some family things I will follow up on more thorough clustering testing later today.

                        Without access to realtime diagnostics it will be hard for me to get a handle on what's going on. But for my purposes, I consider it solved. Do you have any workarounds? G4 PXXX looks like it clears the planner queue from the docs I have read.

                        dc42undefined o_lampeundefined 2 Replies Last reply Reply Quote 0
                        • bg_86undefined bg_86 has marked this topic as solved
                        • dc42undefined
                          dc42 administrators @bg_86
                          last edited by

                          @bg_86 yes G4 clears the movement queue, so does M400.

                          Duet WiFi hardware designer and firmware engineer
                          Please do not ask me for Duet support via PM or email, use the forum
                          http://www.escher3d.com, https://miscsolutions.wordpress.com

                          1 Reply Last reply Reply Quote 0
                          • o_lampeundefined
                            o_lampe @bg_86
                            last edited by

                            @bg_86 said in Raster engrave constantly accelerating and decelerating?:

                            Without access to realtime diagnostics it will be hard for me to get a handle on what's going on.

                            @dc42 Isn't there a buffer underrun counter in the diagnostics? Maybe when setting the debug-log level to warnings? (but debugging_on could induce even more errors in this case...)

                            bg_86undefined 1 Reply Last reply Reply Quote 0
                            • bg_86undefined
                              bg_86 @o_lampe
                              last edited by bg_86

                              Yes, there is. The counter doesn't seem to match the formatting in the documentation, though, so I'm not sure what I'm looking at.

                              M122 results:

                              === MainDDARing ===
                              Scheduled moves 19982, completed 19982, hiccups 0, stepErrors 0, LaErrors 0, Underruns [8106310, 0, 198], CDDA state -1
                              === AuxDDARing ===
                              Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
                              

                              Compare that to the information here: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#stuttering-during-printing

                              @o_lampe no jittering on the 4MB clustered gcode test file I just did at 400MM/SEC, 6000 acceleration. With overscan, it maintains the full 400MM/sec throughout each X axis pass.

                              Seems that jittering issue I reported in my post from yesterday is directly tied to not only the speed of the SD card, but the size of the gcode file. Those files were 90-140MB! I just dreamed up a potential workaround where lightburn posts a beginning-of-file manual gcode to the post that commands a slow move that lasts a few seconds to allow whatever might be causing this issue for the first few seconds of a run to take place, but I haven't tried it yet.

                              bg_86undefined 1 Reply Last reply Reply Quote 0
                              • bg_86undefined
                                bg_86 @bg_86
                                last edited by bg_86

                                @dc42

                                @bg_86 said in Raster engrave constantly accelerating and decelerating?:

                                I just dreamed up a potential workaround where lightburn posts a beginning-of-file manual gcode to the post that commands a slow move that lasts a few seconds to allow whatever might be causing this issue for the first few seconds of a run to take place, but I haven't tried it yet.

                                I just tried this workaround and it did in fact remove the initial jittering I was seeing on the first two or three X raster passes. Just threw in G1 X100 Y100 F500 to create a move that takes 10 seconds or so to complete before the print starts going on the 80MB clustered gcode file. I also noticed that lightburn grbl gcode post is putting a G4 P1 at the beginning of the file for some unknown reason. Tomorrow I will remove that line and my workaround on the offending file without my workaround and see if is in some way contributing to this planner queue jitter issue at the beginning of the file after expanding the planner move queue and the sd card upgrade.

                                dc42undefined 1 Reply Last reply Reply Quote 0
                                • dc42undefined
                                  dc42 administrators @bg_86
                                  last edited by

                                  @bg_86 it may be worth using an Application Class 1 or 2 SD card, because they perform much better at random file reads/writes than tradition SD cards designed for use in digital cameras. See https://www.sdcard.org/developers/sd-standard-overview/application-performance-class/#:~:text=The Application Performance Class 2,of Command Queuing and Cache.

                                  Duet WiFi hardware designer and firmware engineer
                                  Please do not ask me for Duet support via PM or email, use the forum
                                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Unless otherwise noted, all forum content is licensed under CC-BY-SA