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


  • administrators

    @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.



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


  • administrators

    @OwenD said in daemon.g usage cases:

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

    Yes.



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


  • administrators

    @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.



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


  • This daemon.g script is very interesting.

    In what release is it available?


  • Moderator

    @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)


  • administrators

    @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.



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



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


Log in to reply