| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 <2025> | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 <2025> |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Help with bumpless IOC reboot, record linking and initialization concepts |
| From: | Marco Filho via Tech-talk <tech-talk at aps.anl.gov> |
| To: | Michael Davidsaver <mdavidsaver at gmail.com>, "Johnson, Andrew N." <anj at anl.gov> |
| Cc: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
| Date: | Fri, 19 Sep 2025 07:35:50 +0000 |
|
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.
|