LINDY PDU: race condition

[Tom-Willemsen]

As a reflectometry instrument scientist I would like code like the following to work:

g.cset("LINDY_A", 1)
g.cset("LINDY_B", 1)

Where LINDY_A and LINDY_B are two blocks pointing at the status of outputs A & B on the same LINDY ioc.

Currently this has a race condition in the device/ioc/firmware somewhere, which means that the first set is ignored.

---

A workaround is:

g.cset("LINDY_A", 1)
g.waitfor_time(seconds=5)
g.cset("LINDY_B", 1)

acceptance criteria

• above race condition is solved and two consecutive csets work in sequence as expected

There is a "quick-and-easy" solution (@FreddieAkeroyd could you add a bit more detail pls) to add a delay in the db which may resolve this - try this first before debugging further. should be reproducable with an emulator.

discussed in planning 12/06/2025 at 00:12:00

[FreddieAkeroyd]

The issue here is that you can't set an individual output, but need to set them all together. So if two values are set too rapidly the second one uses old details about the state and so overwrites the first one. So options are:

• add a delay at epics level after a set using e.g. seq record, this is a bit like the delay between commands above to give it time to read new status. You can also force a read of a new status, but as it is asynchronus snmp you'd have to wait a short while after forcing an update to be sure a read happened.
• you could update the "current status" cache used in db for a set with what you have just done so the next change before a full read does not overwrite the settings.
• change a db set logic so it doesn't return until it has verified the set has happened via the readback (which it may force to happen a bit sooner)
• change set to force a readback before proceeding to make sure information is up to date

[LowriJenkins]

IOC
SUPPORT
RELEASE NOTES