daemon.g usage cases

Phaedrux

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)

dc42

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

peter247

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

gnydick

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

awitc

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

oliof

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

OwenD

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

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.

OwenD

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

dc42

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

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:

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.