Many of our IOCs use one or more “dbpf” commands in their startup script (sometimes after an epicsThreadSleep) to enable processing after iocInit. Another approach is that the calcout record has a field for each of its input links that indicates whether the
link is connected or not. You could try making use of that to wait until the connection is known to be up instead of inserting a fixed delay, and it should even be possible to handle disconnections and later reconnections for links to remote IOCs if you want
to do that.
On 9/18/25, 5:55 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:
Hi, Ralph, thanks for the help!
I added the record
record(bo, "DISBOOT") {
field(DESC, "Disable on IOC boot")
field(ONAM, "DISABLE")
field(ZNAM, "ENABLE")
field(VAL, "1")
field(PINI, "RUNNING")
field(HIGH, "5")
}
And the field
field(SDIS, "DISBOOT")
To the forwarder record (Not the local nor the global one) and it solved the problem.
It bothers me a bit to add a magic sleep time in the IOC instead of waiting for a known state to complete, but it's the best solution so far without removing the functionality of having hundreds of Local records following what is set in a single global record
- without needing at least tens of fanouts or dfanouts.
Also, if I'm not mistaken even if I had fanouts I would still have this same process-at-initialization problem to solve.
Well, the IOC works without changing the hardware state at boot time now.
Thanks a lot!
Marco
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, September 17, 2025 20:42
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Help with bumpless IOC reboot, record linking and initialization concepts
Every CP/CPP input link sets up a local CA monitor.
When you create a CA monitor, you get an initial update when the connection is made.
That initial update on CP/CPP input links processes the record (as CP/CPP means "process on every update").
Multiple CP/CPP input links (e.g., on a calc record) process the record multiple times. (!)
Using the disable mechanism is a possible workaround. Point all the records that you want to quiet down with their SDIS links to a single disable-after-boot control record, and have that
control record enable the others after the CP/CPP links have connected - time-based (= after a little while) is the simplest way.
Cheers,
~Ralph
