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

    Conditional Loops running slow after SBC addition

    Scheduled Pinned Locked Moved
    Gcode meta commands
    2
    3
    198
    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.
    • wcj97undefined
      wcj97
      last edited by

      I've had a duet 3 mini 5+ running on a machine of mine for about two years. Recently I added an RPi 4b and made the switch to having an SBC. Everything went pretty smooth, except I have a startup.g that runs at the end of my config that is behaving a bit odd. All the startup macro does is run a little animation on my neopixel strips. Ever since updating to the SBC (and updating to firmware 3.5.1) the startup script takes considerably longer to run (about 10x as long). I did notice that there were some minor changes to the M150 code, but I made the necessary updates after updating to 3.5.1.

      There is a delay variable, but changing the value has had no effect since the upgrade. Anyone have any ideas? Am I missing something? TIA!

      var ledbright = 0
      var increment = 5
      var delay = 0.02
      var ledglow = 0
      var glowcount = 3
      var ledcount = 1
      var ubright = 0
      var uincrement = 4
      var bbright = 50
      var bincrement = -1
      
      while var.ledglow < var.glowcount
      	while var.ledbright < 255
      		M150 R255 U0 B50 P{var.ledbright} S16
      		G4 S{var.delay}
      		set var.ledbright = var.ledbright + var.increment
      	while var.ledbright > 0
      		M150 R255 U0 B50 P{var.ledbright} S16
      		G4 S{var.delay}
      		set var.ledbright = var.ledbright - var.increment
      	set var.ledglow = var.ledglow + 1
      M150 P0 S16
      while var.bbright > 25
      	M150 R255 U{var.ubright} B{var.bbright} P255 S{var.ledcount} F1
      	M150 P0 S16
      	set var.ubright = var.ubright + var.uincrement
      	set var.bbright = var.bbright + var.bincrement
      	set var.ledcount = var.ledcount + 1
      	G4 S{var.delay*5}
      ;	M150 R255 U100 B100 P255 S16
      M150 R255 U100 B25 P255 S16
      

      Original Prusa i3 MK2
      Hephaestus (Custom Duet based large format FFF)
      Aeon (Custom belt printer)
      Elegoo Mars

      chrishammundefined 1 Reply Last reply Reply Quote 0
      • chrishammundefined
        chrishamm administrators @wcj97
        last edited by

        @wcj97 By default, RRF waits 25ms between SBC data transfers and per meta condition, one data transfer is needed. That may explain why it behaves differently. Note that regular G-codes are buffered by RRF, so movement should remain smooth in any case.

        If you can live with some increased CPU usage of the SBC while your macro is being executed, you can put M576 S0 at the top of your macro and M576 S25 at the bottom. That will basically eliminate delays between transfers while your macro runs and it should speed up conditional G-codes significantly.

        Duet software engineer

        wcj97undefined 1 Reply Last reply Reply Quote 2
        • wcj97undefined
          wcj97 @chrishamm
          last edited by wcj97

          @chrishamm said in Conditional Loops running slow after SBC addition:

          M576 S0

          That worked perfectly, thank you! I was afraid the issue might have had to do with how the SBC sends commands to the Duet. Startup script is running normally now.

          Original Prusa i3 MK2
          Hephaestus (Custom Duet based large format FFF)
          Aeon (Custom belt printer)
          Elegoo Mars

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