ISISComputingGroup / IBEX

Top level repository for IBEX stories
5 stars 2 forks source link

Galil: indicate better that communications has failed #8524

Open FreddieAkeroyd opened 1 month ago

FreddieAkeroyd commented 1 month ago

As a developer and user i would like it to be clearer that a motor has failed to communicate. At the moment the motor does not go into alarm when comms fails, certainly for a galil but may be true for all motors. Concentrate on Gail for this ticket. The likely reason is that for a galil we read from the cached data record, so it stops upadting but we can still read the previous cache. So we need to propagate it has failed to update into the alarm status of parameters.

Acceptance Criteria

disconnecting communications to a galil controller results in motor record going into alarm

rerpha commented 1 month ago

@FreddieAkeroyd David and I have been working on this this morning. There are two ways to skin a cat I think! See comments in https://github.com/ISISComputingGroup/EPICS-galil/compare/Ticket8524?expand=1

we can either alarm after 3 attempts (like how we disconnect after 3 attempts) or alarm every time. I'm not sure I have much of a preference, but either way propagates the alarm to the motor record and clears when it's successful again.

I'm also nt sure if this ticket covers the "disconnection at startup" - currently that doesn't cause an alarm either. We might have a quick look and see if we can propagate an alarm in that case too, though i dont think its technically in scope of this ticket?

FreddieAkeroyd commented 1 month ago

I don't know how often we have the odd timeout, so it may be best to alarm after 3 attempts like the disconnect so we don't cause parameters to occasionally alarm and then immediately clear and then get a call from users. Would be good if you could also cover the "disconnection on startup" too for completeness.

davidkeymer commented 1 month ago

I don't know how often we have the odd timeout, so it may be best to alarm after 3 attempts like the disconnect so we don't cause parameters to occasionally alarm and then immediately clear and then get a call from users. Would be good if you could also cover the "disconnection on startup" too for completeness.

Thanks for your input, Freddie. Yes, that's what we were thinking too!