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

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

Regardless of my feelings towards dbpfₛ, neither that nor PINI=<All possible options> solved this particular case.
The ways I tried calcout here also didn't work, but maybe some similar attempts will reward me with better results.

Cheers,

Marco

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Maren Purves via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, September 19, 2025 05:31
To: Michael Davidsaver <mdavidsaver at gmail.com>
Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Help with bumpless IOC reboot, record linking and initialization concepts

 

We often use dbpf for temporary changes of alarm thresholds for
instrument temperatures and pressures.
The db contains what they should be if everything was working properly.
I  don't see how that is bad coding.

Maren

On Thu, Sep 18, 2025 at 7:10 AM Michael Davidsaver via Tech-talk
<tech-talk at aps.anl.gov> wrote:
>
> 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.
>
>