Re: Question about Busy Record and ASYN

["Slepicka, Hugo Henrique" <slepicka@slac.stanford.edu>]

Hi Mark and Tom,

Thank you for the clarification and the suggestions.

@Mark I agree with Ernest about Option 2 being the best solution.

Cheers,

Hugo

Sent from my iPhone

On Dec 19, 2017, at 10:09 AM, Williams Jr., Ernest L. <ernesto@slac.stanford.edu> wrote:

Hi Mark,

Option (2) seems like the more optimal solution.

@Andrew, what do you think about this?

Cheers,

Ernest Williams
Dept. Head, Advanced Control Systems
Advanced Instrumentation Research, Technology Innovation Directorate
SLAC National Laboratory, Stanford University

---

From: Mark Rivers <rivers@cars.uchicago.edu>
Sent: Tuesday, December 19, 2017 10:02 AM
To: Williams Jr., Ernest L.; Slepicka, Hugo Henrique; mooney@aps.anl.gov
Cc: EPICS core-talk
Subject: RE: Question about Busy Record and ASYN

 

Hi Hugo and Ernest,

 

Note that I sympathize with the desire to reduce dependencies.  There are a couple of ways that the busy module dependency on asyn could be removed.

 

1) Move the code and reverse the logic, making asyn optionally depend on busy, rather than have busy optionally depend on asyn.  This would simplify the code, because devBusyAsyn.c would just merge into devAsynInt32.c, which would optionally support the busy record.  Currently devBusyAsyn.c is an exact copy of the bo record support in devAsynInt32.c but forcing the logic for the asyn:READBACK info tag to be used without specifying it.

 

2) Change the bo record in EPICS base to have a new mode which does what the busy record does.  Currently the busy record is identical to the bo record except:

  - It does not call recGblFwdLink unless VAL is 0.  This is the critical features which allows it to support completion notification via ca_put_callback().

  - It defines ZNAM=Done and _ONAM_=Busy by default

 

Doing 2) would completely eliminate the need for the busy module and would make the existing devAsynInt32.c require one minor tweak to support the new bo record mode.  It would also make the busy record automatically track any changes to the bo record in new versions of base.

 

Mark

 

 

From: Williams Jr., Ernest L. [mailto:ernesto@slac.stanford.edu]
Sent: Tuesday, December 19, 2017 9:44 AM
To: Mark Rivers; Slepicka, Hugo Henrique; mooney@aps.anl.gov
Cc: Williams Jr., Ernest L.
Subject: Re: Question about Busy Record and ASYN

 

Hi Mark,

 

Thanks, we will now proceed with busy w/asyn support.

 

 

 

Cheers,

 

Ernest Williams

 

---

From: Mark Rivers <rivers@cars.uchicago.edu>
Sent: Tuesday, December 19, 2017 5:56 AM
To: Williams Jr., Ernest L.; Slepicka, Hugo Henrique; mooney@aps.anl.gov
Subject: Re: Question about Busy Record and ASYN

 

Hi Ernest,


> I made an error when building ADCore.  ADCore builds successfully without adding

> the busy support to <ADCore>/configure/RELEASE.local

> This is probably due to the  fact that we did not use the areaDetector top layer, oops.


Actually ADCore, ADSimDetector, etc. will all build OK without busy because ADCore/ADSupport/commonDriverMakefile contains this:


  ifdef BUSY
    $(DBD_NAME)_DBD += busySupport.dbd
    PROD_LIBS        += busy
  endif


So if BUSY is not defined in configure/RELEASE_PRODS.local the applications will build.  However, they will fail at run-time when loading the standard databases because you will get an error trying to load the busy record.


Mark



________________________________
From: Williams Jr., Ernest L. <ernesto@slac.stanford.edu>
Sent: Monday, December 18, 2017 11:28 PM
To: Mark Rivers; Slepicka, Hugo Henrique; mooney@aps.anl.gov
Cc: Williams Jr., Ernest L.
Subject: Re: Question about Busy Record and ASYN


Hi Mark,


This definitely answers it for us.  👍


We use ADCore everywhere; so the busy record is mandatory for us.


I made an error when building ADCore.  ADCore builds successfully without adding

the busy support to <ADCore>/configure/RELEASE.local


This is probably due to the  fact that we did not use the areaDetector top layer, oops.


Thanks for pointing this one out.



Cheers,


Ernest Williams
Dept. Head, Advanced Control Systems
Advanced Instrumentation Research, Technology Innovation Directorate
SLAC National Laboratory, Stanford University


________________________________
From: Mark Rivers <rivers@cars.uchicago.edu>
Sent: Monday, December 18, 2017 9:15 PM
To: Williams Jr., Ernest L.; Slepicka, Hugo Henrique; mooney@aps.anl.gov
Subject: Re: Question about Busy Record and ASYN

Hi Ernest,


> Not sure, where in areaDetector the busy record is use.

> I took look at the ADCore and ADProsilica for example.

> Maybe, I should like directly in synApps?


The busy record is currently used in 9 places in ADCore.  Here they are:


corvette:ADCore/ADApp/Db>grep -A6 "record(busy" *.template
ADBase.template:record(busy, "$(P)$(R)Acquire") {
ADBase.template-   field(DTYP, "asynInt32")
ADBase.template-   field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))ACQUIRE")
ADBase.template-   field(ZNAM, "Done")
ADBase.template-   field(ONAM, "Acquire")
ADBase.template-   field(VAL,  "0")
ADBase.template-}
--
NDCircularBuff.template:record(busy, "$(P)$(R)Capture") {
NDCircularBuff.template-  field(DTYP, "asynInt32")
NDCircularBuff.template-  field(OUT, "@asyn($(PORT) 0)CIRC_BUFF_CONTROL")
NDCircularBuff.template-  field(ZNAM, "Done")
NDCircularBuff.template-  field(ZSV,  "NO_ALARM")
NDCircularBuff.template-  field(ONAM, "Capture")
NDCircularBuff.template-  field(OSV,  "MINOR")
--
NDCircularBuff.template:record(busy, "$(P)$(R)Trigger") {
NDCircularBuff.template-  field(DTYP, "asynInt32")
NDCircularBuff.template-  field(OUT, "@asyn($(PORT) 0)CIRC_BUFF_SOFT_TRIGGER")
NDCircularBuff.template-  field(ZNAM, "Done")
NDCircularBuff.template-  field(ZSV,  "NO_ALARM")
NDCircularBuff.template-  field(ONAM, "Trigger")
NDCircularBuff.template-  field(OSV,  "MINOR")
--
NDFile.template:record(busy, "$(P)$(R)WriteFile")
NDFile.template-{
NDFile.template-    field(DTYP, "asynInt32")
NDFile.template-    field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))WRITE_FILE")
NDFile.template-    field(ZNAM, "Done")
NDFile.template-    field(ONAM, "Write")
NDFile.template-}
--
NDFile.template:record(busy, "$(P)$(R)ReadFile")
NDFile.template-{
NDFile.template-    field(DTYP, "asynInt32")
NDFile.template-    field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))READ_FILE")
NDFile.template-    field(ZNAM, "Done")
NDFile.template-    field(ONAM, "Read")
NDFile.template-}
--
NDFile.template:record(busy, "$(P)$(R)Capture")
NDFile.template-{
NDFile.template-    field(DTYP, "asynInt32")
NDFile.template-    field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))CAPTURE")
NDFile.template-    field(ZNAM, "Done")
NDFile.template-    field(ONAM, "Capture")
NDFile.template-}
--
NDPosPlugin.template:record(busy, "$(P)$(R)Running")
NDPosPlugin.template-{
NDPosPlugin.template-    field(DTYP, "asynInt32")
NDPosPlugin.template-    field(OUT,  "@asyn($(PORT),0)NDPos_Running")
NDPosPlugin.template-    field(ZNAM, "Idle")
NDPosPlugin.template-    field(ONAM, "Running")
NDPosPlugin.template-    field(VAL,  "0")
--
NDProcess.template:record(busy, "$(P)$(R)AutoOffsetScale")
NDProcess.template-{
NDProcess.template-    field(DTYP, "asynInt32")
NDProcess.template-    field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))AUTO_OFFSET_SCALE")
NDProcess.template-    field(ZNAM, "Done")
NDProcess.template-    field(ONAM, "Calculating")
NDProcess.template-}
--
NDTimeSeries.template:record(busy, "$(P)$(R)TSAcquire")
NDTimeSeries.template-{
NDTimeSeries.template-   field(DTYP, "asynInt32")
NDTimeSeries.template-   field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))TS_ACQUIRE")
NDTimeSeries.template-   field(ZNAM, "Done")
NDTimeSeries.template-   field(ONAM, "Acquire")
NDTimeSeries.template-}

The most important is ($P)$(R)Acquire in ADBase.template.  This is the record that is used to start and stop acquisition for all detectors.  Writing to 1 starts acquisition, and when acquisition is done Acquire goes back to 0.  This allows Acquire to be used as the detector trigger with the sscan record.  The scan will only go to the next point when Acquire makes the transition from 1 to 0, which happens when the driver does a callback indicating that the acquisition is complete.

Mark


________________________________
From: Williams Jr., Ernest L. <ernesto@slac.stanford.edu>
Sent: Monday, December 18, 2017 10:21 PM
To: Mark Rivers; Slepicka, Hugo Henrique; mooney@aps.anl.gov
Cc: Williams Jr., Ernest L.
Subject: Re: Question about Busy Record and ASYN


Hi Mark,


Thanks for explaining this one.


Not sure, where in areaDetector the busy record is use.

I took look at the ADCore and ADProsilica for example.

Maybe, I should like directly in synApps?





Cheers,

Ernest Williams



________________________________
From: Mark Rivers <rivers@cars.uchicago.edu>
Sent: Monday, December 18, 2017 12:40 PM
To: Slepicka, Hugo Henrique; mooney@aps.anl.gov
Cc: Williams Jr., Ernest L.
Subject: RE: Question about Busy Record and ASYN


Hi Hugo,



The busy module is written such that the asyn dependency is entirely optional. If you don't put ASYN in busy/configure/RELEASE then it should build fine without asyn.  I worked on that recently, so please use R1-7.  I just tested this, commenting out ASYN in busy/configure/RELEASE and the busy module built fine.  If you are having problems please let me know.



The use case for asyn device support for the busy record is the following:



1) User writes 1 to the busy record to start acquisition using ca_put_callback so it will get a callback when acquisition completes.  This could be a detector trigger for the sscan record for example.

2) Busy record sends 1 to the asyn port driver to start acquisition

3) Driver determines that acquisition is complete and does a callback to asyn device support with the value 0.

4) Device support causes the busy record to process with the new value 0, but without writing this new value to the driver.

5) Busy record now causes ca_put_callback to complete.  This would allow the sscan record can go to the next point in the scan for example.



The busy record is used in this way in the following synApps modules:



areaDetector

measComp

quadEM

mca

dxp

motor



Cheers,

Mark





From: Slepicka, Hugo Henrique [mailto:slepicka@slac.stanford.edu]
Sent: Monday, December 18, 2017 1:37 PM
To: mooney@aps.anl.gov
Cc: Mark Rivers; Williams Jr., Ernest L.
Subject: Question about Busy Record and ASYN



Hi Tim,



Here at SLAC one of our application developers wants to add the Busy Record to her application but the application itself does not depend on Asyn and this is the core reason why I'm sending this email. As we try to make the modules as much as possible independent we do understand that some dependencies can provide a valuable addition to the module and applications being developed with it.



Reading the documentation for the Busy record it was not clear to me the benefit of adding or not the ASYN dependency for the Busy Record, would you mind giving me an use case example?



I took the liberty to add Mark Rivers to this email so I can understand if the Busy Record usage on areaDetector would be somehow affected in case we remove the Busy Record dependency on Asyn.



Thank you,

Hugo