Re: Help with bumpless IOC reboot, record linking and initialization concepts

[Marco Filho via Tech-talk <tech-talk at aps.anl.gov>]

Hi! The calcout option is pretty interesting. However, no way I tried it worked. I tried things like:

record(calcout, "TESTING") {

field(INPA, "$(VMM_GLOBAL)Enable-S")

}

record(calcout, "TESTING2") {

field(INPA, "TESTING.INAV CP")

field(CALC, "A = 2 ? 0 : 1")

}

And adding TESTING2 to SDIS of the forwarder or the local records, but none of that solved the issue.
For now, I will have to go with the timing solution.

That is good enough for the time being.

Thanks for the help,

Marco

---

From: Johnson, Andrew N. <anj at anl.gov>
Sent: Thursday, September 18, 2025 16:54
To: Marco Filho <marco.filho at ess.eu>; EPICS Tech Talk <tech-talk at aps.anl.gov>; Ralph Lange <ralph.lange at gmx.de>
Subject: Re: Help with bumpless IOC reboot, record linking and initialization concepts

 

Hi Marco,

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.

HTH,

- Andrew

-- 

Complexity comes for free, Simplicity you have to work for.

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