Add Pause, resume, run control functionality - #67
Conversation
| _update_software_veto_bit(bit_to_change, config, sock, value) | ||
| except Exception: | ||
| logger.exception("Failed to handle run control update: ") | ||
| # todo: there's no done event here because this is triggered by the run control PV updating. |
There was a problem hiding this comment.
@FreddieAkeroyd how does the ICP handle not being able to stop collection because of a run control PV?
There was a problem hiding this comment.
Do you mean if it is already waiting WAITING? It then knows it can skips the "stop dae hardware" bit as that has already been done so it just proceeds with rest of usual logic.
There was a problem hiding this comment.
as in - what happens if run control in-range PV goes to 0, but the ISISICP can't write to hardware?
There was a problem hiding this comment.
ah ok, in that case isn't it a wider question than run control but what happens if you can't talk to the hardware for begin/end/pause/resume too? ICP tries 6 times with various interface/connection resets, if all that fails it leave original run state displayed and appropriate erros in logs. Script probaby hangs as it usually has a "waitfor runstate"
There was a problem hiding this comment.
begin/end/pause are a bit easier as you can error on a pv set, but because run control is a monitor and then subsequent action it's a bit trickier to "notify" - as you say maybe just putting something in logs is the best we can do.
in terms of retrying, kdaectrl is quite paranoid and retries for setting anything if the readback doesnt match as it's UDP so nothing is guaranteed
There was a problem hiding this comment.
i wasnt sure if there were any mechanisms that currently existed to let the user know that run control had failed but sounds like there isnt
There was a problem hiding this comment.
There is a mechanism to warn via text/email if things have been in a waiting state for more than a specified time, but other than it probably retrying the run control the only user visible thing might be some PVs going into alarm and appearing in the alarm view as they would have comms errors. If it didn't have a comms error but it failed to set the dae register that might not easily show up, but usually there will be either lots of qxtrm errors or it works.
2 participants
No description provided.