EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  <2024 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  <2024
<== Date ==> <== Thread ==>

Subject: Re: pC_->doCallbacksEnum() coming too early
From: Ralph Lange via Core-talk <core-talk at aps.anl.gov>
To: EPICS Core Talk <core-talk at aps.anl.gov>
Date: Wed, 28 Feb 2024 09:53:35 +0100
My 2cts. . . On Tue, 27 Feb 2024 at 23: 51, Mark Rivers via Core-talk <core-talk@ aps. anl. gov> wrote:   ZjQcmQRYFpfptBannerEnd Hi Torsten,   Ø  The PLC gives us some names for enmums, resulting in a call to Ø  pC_->doCallbacksEnum()   doCallbacksEnum()
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
 
ZjQcmQRYFpfptBannerEnd
My 2cts...

On Tue, 27 Feb 2024 at 23:51, Mark Rivers via Core-talk <core-talk at aps.anl.gov> wrote: 
ZjQcmQRYFpfptBannerEnd

Hi Torsten,

 

Ø  The PLC gives us some names for enmums, resulting in a call to
Ø  pC_->doCallbacksEnum()

 

doCallbacksEnum() is only intended to be called when an enum value changes at run-time, i.e. after iocInit.  For enums that the driver determines at initialization you should simply implement the asynPortDriver::readEnum() method.  Device support will call your driver during iocInit to read the enum values/strings/severities for all records with enum VAL fields.

 

testAsynPortDriver has an example here:

https://github.com/epics-modules/asyn/blob/a94a78987a99b1c36bbd641a67341069dc5d627e/testAsynPortDriverApp/src/testAsynPortDriver.cpp#L340

 

It also has an example of using doCallbacksEnum(), which it does when the vertical gain is changed at run time.

https://github.com/epics-modules/asyn/blob/a94a78987a99b1c36bbd641a67341069dc5d627e/testAsynPortDriverApp/src/testAsynPortDriver.cpp#L374


Been there...
The problem is that these are synchronous (blocking) calls. If you have many devices and/or devices that are handled asynchronously, this is likely to screw up your IOC startup.

I think the most reasonable way to handle the situation is a bit more complex:
  • from the driver, do the requests to the devices as early as possible after the devices are up (and do the requests in parallel),
  • when the responses come in, queue them,
  • start the worker thread(s) for the queues (that push the values into the database) when the IOC is fully up, through the interruptAccept initHook.
That will work no matter if the IOC becomes ready before, during or after the initial device readout is finished.
Queueing incoming responses is always a good idea that helps with bursts or high-load-on-the-IOC-host situations.

Cheers,
~Ralph

Replies:
Re: pC_->doCallbacksEnum() coming too early Torsten Bögershausen via Core-talk
References:
pC_->doCallbacksEnum() coming too early Torsten Bögershausen via Core-talk
Re: pC_->doCallbacksEnum() coming too early Johnson, Andrew N. via Core-talk
RE: pC_->doCallbacksEnum() coming too early Mark Rivers via Core-talk

Navigate by Date:
Prev: Build failed: EPICS Base 7 base-7.0-1107 AppVeyor via Core-talk
Next: Re: pC_->doCallbacksEnum() coming too early Torsten Bögershausen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  <2024
Navigate by Thread:
Prev: RE: pC_->doCallbacksEnum() coming too early Mark Rivers via Core-talk
Next: Re: pC_->doCallbacksEnum() coming too early Torsten Bögershausen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  <2024
ANJ, 28 Feb 2024 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·