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

      Just wanting to get my head around the usage of daemon.g

      • What is the “typical” frequency that this file is checked/run?
      • Can I call sub macros from it and if so, are the blocking or running in a thread of their own?
      • Is there any danger of the processing time used in this file interfering with the print queue?

      I can see it’s first use for checking temp runaway while not actually printing.
      So let’s say we don’t want to do that more than once per 15 seconds.
      We can use an IF statement and I guess a tick count to see if we need to run it? I seem to remember the object model having a time since started?
      Probably need a global variable to make that work though.
      If we use the now modified G4, that would hold up running of any other functions/procedures in the file would it not?

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

        @OwenD said in daemon.g usage cases:

        Just wanting to get my head around the usage of daemon.g

        • What is the “typical” frequency that this file is checked/run?

        It runs at the same rate as all the other GCore sources, with round-robin scheduling.

        • Can I call sub macros from it and if so, are the blocking or running in a thread of their own?

        You can call submacros, but they don't run in a separate thread.

        • Is there any danger of the processing time used in this file interfering with the print queue?

        Possibly, if you do something that uses a lot of resources. If you implement in loop within daemon.g then I recommend that you include at least one G4 command within the loop, to limit the amount of resources that it uses.

        I can see it’s first use for checking temp runaway while not actually printing.
        So let’s say we don’t want to do that more than once per 15 seconds.
        We can use an IF statement and I guess a tick count to see if we need to run it? I seem to remember the object model having a time since started?
        Probably need a global variable to make that work though.
        If we use the now modified G4, that would hold up running of any other functions/procedures in the file would it not?

        Yes, a G4 command it will delay execution of subsequent commands in that file.

        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 1 Reply Last reply Reply Quote 0
        • OwenDundefined
          OwenD @dc42
          last edited by

          • Is there any danger of the processing time used in this file interfering with the print queue?

          Possibly, if you do something that uses a lot of resources. If you implement in loop within daemon.g then I recommend that you include at least one G4 command within the loop, to limit the amount of resources that it uses.

          Just to fully clarify..
          Does G4 pass control back to the main process when used in a loop?
          Not sure of the terminology in C, but in Delphi I’d use “application.processmessages” to ensure the loop didn’t “freeze” the main process.
          Is the new implementation of G4 essentially calling processmessages for the specified time?

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

            @OwenD said in daemon.g usage cases:

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

            Yes.

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