Experimental Physics and
| |||||||||||||||
|
This Message Is From an External Sender
This message came from outside your organization.
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
| ||||||||||||||
ANJ, 29 Feb 2024 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |