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

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 9/19/25 00:35, Marco Filho wrote:

Ah, I think I didn't properly understand this email on the first read.

> Generally, I have found that the more effective way to coordinate connect/disconnect is at the driver level.  Generally with a special device support to drive on-connect processing.

You mean disconnecting from the actual equipment before the PVs are initialized and then only connecting once all the links are properly initialized?
If so, how do you detect at driver level that that has happened?

I think you have right idea, although the other way around.  My thinking is that a driver initializes into a latched "error" state, which is cleared by processing a record.  I like this approach because it naturally leads to handling the initial connection the same as a re-connect.

In the asyn language, I suppose this would mean starting with autoConnect=0, then setting it to 1 from a asynRecord.

I can imagine connecting some record to a calcout INAV field and sending that value to the driver, but that only guarantees that that particular record is initialized, no?

Correct, or similar conditions with eg. IVOA "Don't drive outputs".  And so far this has been enough for the cases I have encountered.

Is there a better approach?

Thinking about it, it might help the situation if iocInit() sequencing waited for local CA links to become connected.  This turns out not to be so difficult to achieve.

https://github.com/epics-base/epics-base/pull/713

Marco

---

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

 

On 9/18/25 07:54, Johnson, Andrew N. via Tech-talk wrote:

Many of our IOCs use one or more “dbpf” commands in their startup script (sometimes after an epicsThreadSleep) ...

Nooooooo!

Finding a bunch of random, rarely commented, dbpf calls in an IOC start script is to me a bad code smell.  The same goes for sleeps, only more so.  Please investigate 'field(PINI, "RUNNING")', or look at other ways to actually synchronize startup.

... it should even be possible to handle disconnections and later reconnections for links to remote IOCs if you want to do that.

imo. any well written driver for an ethernet attached device __needs__ to do this.

Generally, I have found that the more effective way to coordinate connect/disconnect is at the driver level.  Generally with a special device support to drive on-connect processing.