daemon.g looping

oozeBot

I'm starting to play with daemon.g but ran into a problem. It is quite possible I caused the issue, so I'd like feedback on how to best structure the code. Also, is daemon.g run in or out of process?

We are using Duet3/RPi combos and are currently running 3.2B1..

As a test, I created a simple mCode (using execonmcode) which is currently only logging the timestamp when it is called to a log file. It does this sub-second. I then told it to wait 10 seconds using G4 S10. This works, but there was a significant side effect.

; daemon.g
M5575
G4 S10 ; delay 10 seconds

What I found is that with the daemon.g running the above snippet, G29 S0 fails every time with a large enough probe set. It has made it to various probe points around the bed, but it ends up failing every time in various ways (probe doesn't extend, drives nozzle into the bed, then fails; probe the same point max number of tries, then fails; and once it just stopped).

I renamed daemon.g and was able to successfully run G29 S0 without issue the first try.

So, is this an issue with the way I've structured my daemon.g file? Is there a better way to make it wait 10 seconds?

And advice on this will be appreciated.. Thanks!

dc42

I think this is an issue with the comms between the Duet and the SBC. Please check whether it works using release 3.2 beta 2.

oozeBot

@dc42 thanks, I am willing to upgrade once more now that there is a clear path backwards to 3.2b1, but please see the issue I escalated yesterday that we experienced which blocked us from using the latest beta.

https://forum.duet3d.com/topic/19123/3-2b2-duet3-rpi-with-toolboard-g30-issue-with-bltouch