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

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

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 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?
Is there a better approach?

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.