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

    Reducing time between jobs

    Scheduled Pinned Locked Moved
    General Discussion
    2
    3
    139
    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.
    • mynameisdevundefined
      mynameisdev
      last edited by

      I'm building a CNC machine which paints pictures. Each picture is its own Gcode file and occupies a small area of a larger canvas - the pictures usually come in batches.

      I have written a simple queue manager which runs available jobs one after the other so I don't have to manually select and run them which is great as I don't have to babysit the machine while in the studio.

      I have noticed that there is a delay of 5-10 seconds between one job finishing and the next one starting - is there a way of reducing this time lag? A few seconds doesn't seem like a lot but for many jobs in sucsession, it adds up quickly to minutes at a time of the machine doing nothing. I imagine that this delay between jobs is actually a short delay at the end of one job and a different short delay at the start of the next job (there is a delay at the start of the process between the first request being sent and the machine starting for the first time at the top of the queue).

      The queue manager is written in python and makes use of the HTTP interface - it works like this:

      //Pseudo code, not actual python
      //Assume all gcode is already on the SD card
      //Assume we have a list of all the g-code file we want to run
      
      print("Start queue")
      foreach gcodeFile in listOfFiles:
          //Make a HTTP request which starts the first job in the list
          httpRequest("my_duet_address.local/rr_gcode?gcode='M32 "0:/gcodes/" + gcodeFile)
          
          //make periodic requests to the status endpoint to see if the machine is idle or not
          while(true):
              response =  httpRequest("my_duet_address.local/rr_status")
              machineStatus = response.json.get("status")
              //If the machine is idle, leave this polling loop and go back to the top of the foreach
              if machineStatus = "I":
                  break;
              //Wait a small arbitrary amount of time to not overwhelm the HTTP interface on the duet
              sleep(0.25)
      
      print("All done")
      

      While there is a little delay in my status polling loop it is much shorter than the time between one job ending and another starting.

      Are there any configuration options I can change on the duet to reduce this gap time?

      Many thanks!
      D

      gloomyandyundefined 1 Reply Last reply Reply Quote 0
      • gloomyandyundefined
        gloomyandy @mynameisdev
        last edited by

        @mynameisdev It sounds like the delay you are seeing is almost certainly either at the start or end of your prints, what do you have in the start/end of these gcode files?

        mynameisdevundefined 1 Reply Last reply Reply Quote 0
        • mynameisdevundefined
          mynameisdev @gloomyandy
          last edited by

          @gloomyandy here are some example start and end snippets from files I've been running - do you see anything which looks like it might cause this delay?

          ;FLAVOR:Marlin
          ;TYPE:WALL-OUTER
          G1 Z-25.0 F4800
          G1 F40000
          G1 X766.234 Y2018.286 Z-4.0
          G1 X766.348 Y2016.803 Z-4.0
          G1 X766.862 Y2010.128 Z0.601 E0.0243700882
          G1 X764.58 Y1989.589 Z1.165 E0.0620192331
          G1 X761.862 Y1974.838 Z-4.0
          G1 X759.31 Y1960.983 Z-4.0
          ...
          ...
          G1 X1027.692 Y2299.21 Z1.521 E0.0046168879
          G1 X1026.736 Y2300.688 Z1.508 E0.0052808428
          G1 X1025.724 Y2302.405 Z1.491 E0.0059793560
          G1 X1024.768 Y2304.19 Z1.472 E0.0060749237
          G1 X1023.866 Y2306.046 Z1.451 E0.0061910443
          G1 X1022.928 Y2308.18 Z1.425 E0.0069935888
          G1 X1022.092 Y2310.296 Z1.398 E0.0068259599
          G1 X1021.308 Y2312.497 Z1.368 E0.0070099653
          G1 X1021.308 Y2312.497 Z-4.0 E0.0161040000
          
          ;Print End Script
          G1 Z-25.0 F500
          
          ;FLAVOR:Marlin
          ;TYPE:WALL-OUTER
          G1 Z-25.0 F4800
          G1 F40000
          G1 X296.07 Y2098.485 Z-4.0
          G1 X291.339 Y2084.251 Z0.618 E0.0470832812
          G1 X305.337 Y2088.952 Z0.634 E0.0442989046
          G1 X313.206 Y2091.849 Z0.644 E0.0251560098
          G1 X326.903 Y2097.612 Z0.663 E0.0445800746
          G1 X330.952 Y2099.163 Z0.667 E0.0130076963
          G1 X335.86 Y2100.829 Z0.671 E0.0155491583
          ...
          ...
          G1 X572.105 Y2354.19 Z1.187 E0.0001434364
          G1 X572.016 Y2354.171 Z1.171 E0.0002772039
          G1 X571.514 Y2354.023 Z1.121 E0.0015772356
          G1 X569.362 Y2353.29 Z0.999 E0.0068300434
          G1 X569.362 Y2353.29 Z-4.0 E0.0149970000
          
          ;Print End Script
          G1 Z-25.0 F500
          
          

          I'm running a g-code generator which we developed inhouse so we have lots of control over what it does.

          I know the final Z move is slow, but it doesn't take anywhere near 10 seconds

          Any ideas?
          Cheers!
          D

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