Re: pC_->doCallbacksEnum() coming too early

[Torsten Bögershausen via Core-talk <core-talk at aps.anl.gov>]

Hej Experts, thanks so much for the help. Right now I have a somewhat hackish version. #if 0 /* This version gives: warning: 'rset' is deprecated [-Wdeprecated-declarations] rset *prset; */ #include <dbAccess. h> /* interruptAccept */

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

Hej Experts,
thanks so much for the help.


Right now I have a somewhat hackish version.

#if 0
/* This version gives:
    warning:
       'rset' is deprecated [-Wdeprecated-declarations]
     rset            *prset;
*/
#include <dbAccess.h> /* interruptAccept */
#else
#include <dbCoreAPI.h>
DBCORE_API extern volatile int interruptAccept;
#endif

But it works well.
Ralhp, I think that I do what you suggest already.
When connecting to the PLC, all data is read as fast as possible.
However, we are talking about 20 motors, which have 1--2 enums.
Not Megabytes of data ;-)
All this enum-values (for the mbbi) are today already stored
in a bunch of asyn-parameters.

So it was "only" the determination, when is it a good time for the 
callback, that was missing.
Thanks again.



On 2024-02-28 09:53, Ralph Lange via Core-talk wrote:
> 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 <mailto: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://urldefense.us/v3/__https://github.com/epics-modules/asyn/blob/a94a78987a99b1c36bbd641a67341069dc5d627e/testAsynPortDriverApp/src/testAsynPortDriver.cpp*L340__;Iw!!G_uCfscf7eWS!cNPFGdiAvPevZU44dGFiDBVJDU6UCKIHT814ujg1PMT3Y6IUhS7efeCJLa1uEeA5WaHYqwsTz0fMuYpskNU$ <https://urldefense.us/v3/__https://github.com/epics-modules/asyn/blob/a94a78987a99b1c36bbd641a67341069dc5d627e/testAsynPortDriverApp/src/testAsynPortDriver.cpp*L340__;Iw!!G_uCfscf7eWS!fE_LD5q32_jjj9Y2BpELUbcw3yXiB5OnxyWCR4yUcD48lMAvhT1_A34lEQ5JZaBnQaPIH8NUbIHoKoZgjJ-Vp9EB5zY$>____
>
>     __ __
> 
>     It also has an example of using doCallbacksEnum(), which it does
>     when the vertical gain is changed at run time.____
> 
>     https://urldefense.us/v3/__https://github.com/epics-modules/asyn/blob/a94a78987a99b1c36bbd641a67341069dc5d627e/testAsynPortDriverApp/src/testAsynPortDriver.cpp*L374__;Iw!!G_uCfscf7eWS!cNPFGdiAvPevZU44dGFiDBVJDU6UCKIHT814ujg1PMT3Y6IUhS7efeCJLa1uEeA5WaHYqwsTz0fM2ymOgHM$ <https://urldefense.us/v3/__https://github.com/epics-modules/asyn/blob/a94a78987a99b1c36bbd641a67341069dc5d627e/testAsynPortDriverApp/src/testAsynPortDriver.cpp*L374__;Iw!!G_uCfscf7eWS!fE_LD5q32_jjj9Y2BpELUbcw3yXiB5OnxyWCR4yUcD48lMAvhT1_A34lEQ5JZaBnQaPIH8NUbIHoKoZgjJ-VnvkyVf8$>
>
> 
> 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