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

    daemon.g usage cases

    Scheduled Pinned Locked Moved
    Beta Firmware
    8
    19
    2.8k
    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.
    • OwenDundefined
      OwenD
      last edited by

      I've had a bit of a play with this and have noticed an interesting effect of G4 within daemon.g

      I started with a basic test, checking voltage at no less than 60 second intervals

      ; daemon.g
      ;Constantly runs in background to check outputs etc
      if {boards[0].vIn.current >= 23.6} ; check current PSU voltage
      	echo "Voltage OK : " ^ boards[0].vIn.current ; display OK message and current voltage
      else
      	echo "Voltage low : " ^ boards[0].vIn.current ; display low voltage warning & current voltage
      G4 S60 ; delay running again or next command for at least 60 seconds
      

      It works as expected, however I note that

      • The printer goes from idle to busy status for the duration of the G4 time.

      Q: Will this affect things like motor idle timeout?

      • It's near impossible to delete the daemon.g file in this case as the file is open almost as soon as the duet boots for the duration of the G4.
        I was able to rename it and then delete it though.
        No such problem (understandably) when not using G4

      Q: Is there any plan for a G Code to start/kill the daemon in case someone accidentally puts a command in there that has bad consequences?

      I had thought I'd seen some sort if tick count function in the object model which would probably be a better way of doing something like this (once we have variables), but can't find any reference.

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

        @OwenD said in daemon.g usage cases:

        It works as expected, however I note that

        The printer goes from idle to busy status for the duration of the G4 time.

        Thanks for reporting this, I will look into it. It probably makas sense for the busy/idle status to ignore the daemon.

        Q: Will this affect things like motor idle timeout?

        No. However, I have noticed that the G4 commands don't get treated correctly when running a simulation. I will fix this.

        It's near impossible to delete the daemon.g file in this case as the file is open almost as soon as the duet boots for the duration of the G4.
        I was able to rename it and then delete it though.

        That is the recommended approach when you want to change daemon.g.

        Q: Is there any plan for a G Code to start/kill the daemon in case someone accidentally puts a command in there that has bad consequences?

        Not currently, just rename daemon.g to something else if that happens.

        I had thought I'd seen some sort if tick count function in the object model which would probably be a better way of doing something like this

        No, because it would have to sit in a pulling loop constantly checking whether the time has expired. Using G4 tells the firmware that you are delaying, so it can do something more efficient.

        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

        OwenDundefined gnydickundefined 2 Replies Last reply Reply Quote 1
        • OwenDundefined
          OwenD @dc42
          last edited by

          @dc42 said in daemon.g usage cases:

          @OwenD said in daemon.g usage cases:

          I had thought I'd seen some sort if tick count function in the object model which would probably be a better way of doing something like this

          No, because it would have to sit in a pulling loop constantly checking whether the time has expired. Using G4 tells the firmware that you are delaying, so it can do something more efficient.

          I was thinking more along the lines of declaring two variables in config.g and simply using an if statement rather than a while x > y loop.
          Unless I'm misunderstanding, G4 is going to delay anything else in the daemon.g, which I guess is fine if the intent is for it to carry out a limited number of functions.

          e.g.
          in config.g

          var "delay"= 60000 ; milliseconds
          var "current_time"= gettickcount() ; 
          

          In daemon.g

          if {gettickcount()-current_time < delay)
                 {do some fancy stuff here not less than every 60 seconds}
                current_time=gettickcount() ; reset counter
          else
               {do something else - or nothing}
          
          carry on with rest of daemon.g without delay 
          
          dc42undefined 1 Reply Last reply Reply Quote 0
          • fmaundefined
            fma
            last edited by

            This daemon.g script is very interesting.

            In what release is it available?

            Frédéric

            Phaedruxundefined 1 Reply Last reply Reply Quote 0
            • Phaedruxundefined
              Phaedrux Moderator @fma
              last edited by

              @fma said in daemon.g usage cases:

              This daemon.g script is very interesting.

              In what release is it available?

              Starting with 3.01-RC3, but if you want to experiment with it use the latest RC (currently RC11)

              Z-Bot CoreXY Build | Thingiverse Profile

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

                @OwenD said in daemon.g usage cases:

                @dc42 said in daemon.g usage cases:

                @OwenD said in daemon.g usage cases:

                I had thought I'd seen some sort if tick count function in the object model which would probably be a better way of doing something like this

                No, because it would have to sit in a pulling loop constantly checking whether the time has expired. Using G4 tells the firmware that you are delaying, so it can do something more efficient.

                I was thinking more along the lines of declaring two variables in config.g and simply using an if statement rather than a while x > y loop.
                Unless I'm misunderstanding, G4 is going to delay anything else in the daemon.g, which I guess is fine if the intent is for it to carry out a limited number of functions.

                e.g.
                in config.g

                var "delay"= 60000 ; milliseconds
                var "current_time"= gettickcount() ; 
                

                In daemon.g

                if {gettickcount()-current_time < delay)
                       {do some fancy stuff here not less than every 60 seconds}
                      current_time=gettickcount() ; reset counter
                else
                     {do something else - or nothing}
                
                carry on with rest of daemon.g without delay 
                

                There is a tick count, it's called state.uptime. But you will have to simulate a variable in order to do what you want. Also, if you leave your printer on for long enough, state.uptime will wrap round.

                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

                peter247undefined 1 Reply Last reply Reply Quote 0
                • peter247undefined
                  peter247 @dc42
                  last edited by

                  @dc42

                  What to switch the heaters off after say 5 minutes.

                  Have we got variables and a well to monitor the passing of time now in 3.1.1 ?

                  So I want to set the current time in the pause trigger and look for that time plus a delay to trigger a switch off ?

                  Ender 5 plus linear rail and hemera powered by duet 2 wifi , CR10s pro v1 with bltouch mostly stock , BLV mgn Cube slowly being built powered by duet 3 mini 5+

                  1 Reply Last reply Reply Quote 0
                  • gnydickundefined
                    gnydick @dc42
                    last edited by

                    @dc42 are you sure renaming it will work? I've seen that filesystem operations fail while files are in use. I realize a rename is not the same as saving a new version, but the filesystem semantics of the duet platform don't seem to conform with other common operating systems.

                    1 Reply Last reply Reply Quote 0
                    • awitcundefined
                      awitc @dc42
                      last edited by

                      @dc42 said in daemon.g usage cases:

                      @OwenD said in daemon.g usage cases:

                      Does G4 pass control back to the main process when used in a loop?

                      Yes.

                      I have some issues understanding the G4 command. I assumed that it works like a delay, which makes the 'thread' dormant, so that the next task in line can get the processing power. I have used it in a daemon.g:

                      var trigger = 0
                      
                      while true
                      
                      	if sensors.analog[9].lastReading  > global.pump_trigger_temp && var.trigger == 0
                      		set var.trigger = 1
                      		
                      		M42 P1 S1		; enable pump		
                      		M106 P3 S255	; enable fans
                      		
                      	if sensors.analog[9].lastReading  < global.pump_trigger_temp
                      		set var.trigger = 0
                      		M42 P1 S0 		; disable pump
                      		G4 S30			; wait 30 seconds
                      		M106 P3 S0 		; disable fans
                      			
                      	G4 S1
                      	
                      	
                      	
                      

                      where a pump and radiator fans are controlled. The program works fine, but I experienced some pauses in my printing, occuring quite randomly. I made a forum post about it. I feel quite silly now, because the delays I experienced might align with the G4 S30 command.

                      I am perplexed, as the G4 S1 command does not seem to block the events, but the G4 S30 is probably the culprit of my problems. What would be a way of creating a non-blocking delay command in a daemon.g?

                      oliofundefined OwenDundefined 2 Replies Last reply Reply Quote 0
                      • awitcundefined awitc referenced this topic
                      • oliofundefined
                        oliof @awitc
                        last edited by

                        @awitc G4 is a blocking wait. If you wanted that loop to only check itself every 30 seconds, you would need to carry the time and check whether more than 30 seconds passed since the last check.

                        <>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
                        • OwenDundefined
                          OwenD @awitc
                          last edited by

                          @awitc
                          The G4's in daemon.g will (should) only affect daemon.g
                          So in your case, the G4 S1 ensures that the while loop doesn't run at a frequency of less than 1 second.
                          The G4 S30 will only come into play if your second condition is met and will then wait 30 seconds between turning off the pump and the fan.
                          However it will mean that particular iteration of the will loop will have taken at least 31 seconds.

                          your var trigger = 0 will only be executed the first time the daemon is run because the use of the while true loop will prevent the "pointer" from leaving the loop thereafter. Your code suggests you are aware of this.

                          You would be more likely to have problems with daemon.g affecting a print if you either

                          • used a while true loop, but did NOT have any G4 delays
                          • Used a command in daemon.g affected print speed in some way
                          • used a blocking command like maybe M116, M291 S>2 etc

                          That said, I have found that daemon.g will interfere with some macros.
                          I have some that play music using M300. My daemon.g is quite complex and definitely affects the playing of these.

                          awitcundefined 1 Reply Last reply Reply Quote 1
                          • awitcundefined
                            awitc @OwenD
                            last edited by awitc

                            @OwenD

                            Yes, my goal was to have a function checking a sensor state with 1 second intervals, and to disable fans with a 30 second delay. However, I found the G4 blocking, ie. in one of my prints a typical layer takes about 5 seconds to finish, but some of them are ~35 seconds. This behaviour disappears completely when I do not use the daemon.g, and I determined it to be for sure linked to the G4 S30 command.

                            This is why I am left confused as to what is the exact behaviour of G4 in daemon.g.

                            OwenDundefined dc42undefined 2 Replies Last reply Reply Quote 0
                            • OwenDundefined
                              OwenD @awitc
                              last edited by

                              @awitc
                              I suggest you start a new thread detailing what you have found and include details of firmware versions etc.
                              It's one for @dc42 to look at.

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

                                @awitc what firmware version are you using? When daemon.g was first introduced, execution of a G4 command by daemon.g caused the machine to wait for motion to stop. In later firmware versions a G4 command won't wait for motion to stop unless the motion was commanded by the same input channel, so in this case only if motion was commanded by daemon.g.

                                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

                                awitcundefined 1 Reply Last reply Reply Quote 0
                                • awitcundefined
                                  awitc @dc42
                                  last edited by awitc

                                  @dc42

                                  I am using the latest version of the firmware, 3.4.6.

                                  Here I have created a post regarding the pausing: link.

                                  Edit:
                                  fccf6844-3430-4cc3-8f3a-48fa116e38d3-obraz.png
                                  I have gone through the information regarding daemon.g on the docs page once more. Is it possible that a G4 S30 is making the code to be 'a loop that takes a long time to complete'? I assumed that no matter the parameter of G4, it will return the control to the main process.

                                  I will try to redo my daemon.g to contain a loop with shorter pauses, instead one G4 command.

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