Daemon.g not running when printer in Busy

e4d

@T3P3Tony here's my daemon.g :

while global.runDaemon == true

	echo "daemon"
	
	; Voyant Pause
	if state.status = "paused"
		M42 P13 S1
	else
		M42 P13 S0
		
	;voyant rouge
	if heat.heaters[0].current >= 50 || heat.heaters[3].current >= 50
		M42 P17 S1
	else 
		M42 P17 S0

	;G4 S1
	G4 P200

I tried using

M669 X1:0:0:0:0 Y0:1:0:0:0 Z0:0:1:0:0 A0:0:0:1:0 C0:0:0:0.5:1 S600

to update even more frequently but with no success. I also have some light on/off in my daemon so the issue is not only console related

T3P3Tony

@e4d i wont not have such a shot wait between loops.

Try the M118 P3 method to echo to ensure you daemon is running.

e4d

@T3P3Tony i tried putting G4 S1 to reduce the time between loops and put M118 P3 S"daemon" in daemon.g. When doing a long slow move the console is not showing anything.

Is it the daemon.g not running ?

T3P3Tony

@e4d possibly not, is your global.runDaemon set to true?

send

echo global.runDaemon

e4d

@T3P3Tony it is set to true I checked with "echo global.runDaemon". The message "daemon" is showing every second until I do a "G1 X50 F50" starting from X0 then there's nothing in the console. When the movement is finished the message is back

T3P3Tony

@e4d ahhh right, ok so thats a question for @dc42 then about segmentation. It may be that even though the message is coming from the daemon its not processed until after the move has finished.

dc42

@e4d which firmware version are you using? The daemon should run concurrently with motion as long as it doesn't try to execute motion-related commands. However, in some older firmware versions the G4 command caused it to wait for motion to stop.

e4d

@dc42 i'm running RRF 3.4.5 and DWC 3.4.5 on a Duet3 6HC.
I tried to do further testing. It seems that if there's something more than the M118 P3 it doesn't work anymore. I tried putting a M42 in the daemon after the M118, nothing more, and it does'nt work.

e4d

@dc42 do you have any idea how I could solve this segmentation problem ?

dc42

@e4d I can see that the M42 command might get held up if you are doing a G2 or G3 move, or a long linear move and you have segmentation enabled. I think I need to change the logic so that when M42 is executed by the daemon, and the daemon hasn't commanded any movement since it last waited for movement to stop, the command is executed immediately without any attempt to sync it to the movement commands already queued.

Meanwhile, you may be able to get this working by putting one of the parameters in { } for example M41 P{13} S1. This will make the parser think that there is an expression to be evaluated, and in current firmware it will not attempt to sync the command with motion.