what might stop daemon.g running?

achrn

@dc42 M122 includes:

Daemon:
Buffered code: M106 P4 S1 L0.25 B0.2 H6 T35:36 C"encl" ; fan thermostatic
==> 92 bytes
Executing macro daemon.g, started by system
Number of flush requests: 1

I have to say I don't know how that fan definition got in there! It's not in the (current) daemon.g.

As implied, I have been fiddling with daemon.g while the print is running (which is presumably not very bright), and a version of daemon.g did have some fan commands, but not (intentionally) creating a thermostatic control on one - it had simple M106 P4 S0.6 type things. Presumably at some point I've inadvertently saved something I shouldn't into daemon.g, and now therefore I don't actually know what is in the daemon.g it's running.

Is there a way to kick daemon.g to tell it to to re-read the daemon.g file and start again, without upsetting a running print job?

cosmowave

@achrn I think deamon.g will be periodically "reloaded" (every 10 seconds).

achrn

@cosmowave said in what might stop daemon.g running?:

@achrn I think deamon.g will be periodically "reloaded" (every 10 seconds).

It's not reloading - it is still (two hours later) stuck on the same line of 'buffered code' which isn't in the current daemon.g (and probably hasn't been for at least 12 hours, because I haven't changed daemon.g since yesterday, though since I don't know how it got there, I can't be definitive about when it got there).

It's not a big problem - I can operate the vent manually, and do a M999 when the job completes.

cosmowave

@achrn Eventually it is possible to rename deamon.g in the sys folder. But i think it will not help with "unstucking" the system...

dc42

@achrn this is the section of the M122 report that I was interested in:

=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty

achrn

@dc42 OK:

=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is doing "G1 X17.202999 Y17.684000 E0.256060" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is doing "M106 P4 S1 L0.250000 B0.200000 H6 T35:36 C"encl"" in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.

jay_s_uk

@achrn maybe rename daemon.g, give it a couple of minutes and then name it back

achrn

@jay_s_uk
Renaming it achieves nothing. Deleting it achieves nothing. Putting a new different one back in achieves nothing. In both the parts of M122 I've quoted up thread it stays stuck on doing an M106.

Anyway, I'm now on layer 2496 of a 3180 layer print so I become less and less inclined to tamper in case I do something bad and it fails again (this being second attempt - first time it failed with some dodgy wiring, now replaced).

achrn

Just for completeness: Job completed. I issued M999 and it's working fine now.

Phaedrux

Note to self. Don't muck with a running macro file.