EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: AreaDetector bindings and RBV propagation
From: Mark Rivers <[email protected]>
To: 'Iain Marcuson' <[email protected]>, "[email protected] >> EPICS Tech Talk" <[email protected]>
Date: Tue, 9 May 2017 12:43:22 +0000
Hi Iain,

Note that what you are doing with the GetStatus record is OK, but it means that that DetectorState_RBV will only update when the GetStatus record polls the driver.  That is not the "normal" design of an areaDetector driver.  Rather the DetectorState_RBV record will be updated whenever your driver does something that causes the state to change, either because of some user interface through the writeInt32, writeFloat64, etc. methods, or through a driver thread that detects when acquisition has stopped, etc.

Mark

________________________________________
From: Mark Rivers
Sent: Monday, May 08, 2017 4:37 PM
To: 'Iain Marcuson'; [email protected] >> EPICS Tech Talk
Subject: RE: AreaDetector bindings and RBV propagation

Hi Iain,

> 7. Caput $(P)$(R)DetectorState_RBV 2.
> 8. Caget $(P)$(R)DetectorState_RBV.  It is "Readout" (as expected from ADBase.template, numeric value 2).
> 9. Caput $(P)$(R)GetStatus 1.  Initially reported value is 3, not 2 as would be expected from step 8.

DetectorState_RBV is an input record, not an output record.  That means that when you wrote the value 2 to it with caput it changed the value in the record, but that value was not sent to the driver.  Only output records send their values to the driver, not input records.  So the last value the driver had was 3, not 2, and what you observe is expected.

>10. Caget $(P)$(R)DetectorState_RBV.  It is "Readout" (numeric value 2), not 3 as would be expected from step 9.

That does not make sense to me.  If your driver called setIntegerParam(ADStatus, 3) and then callParamCallbacks(addr) then the record should have the value 3, not 2.

I just tried to reproduce your observation with the simDetector driver and I cannot.

Detector is currently idle.
I write 2 to :DetectorState_RBV as you did:

corvette:ADCore/ADApp/Db>caput 13SIM1:cam1:DetectorState_RBV 2
Old : 13SIM1:cam1:DetectorState_RBV  Idle
New : 13SIM1:cam1:DetectorState_RBV  Readout

I then do a caget to verify that the value is 2 (Readout):
corvette:ADCore/ADApp/Db>caget 13SIM1:cam1:DetectorState_RBV
13SIM1:cam1:DetectorState_RBV  Readout

I then start acquisition of the driver.  When the driver starts acquisition it calls setIntegerParam(ADStatus, ADStatusAcquire)
I then read the value of DetectorState_RBV:

corvette:ADCore/ADApp/Db>caget 13SIM1:cam1:DetectorState_RBV
13SIM1:cam1:DetectorState_RBV  Acquire

Note that it is Acquire, not Readout, so the value that the simDetector driver wrote is indeed the current value in the record.

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Iain Marcuson
Sent: Monday, May 08, 2017 3:29 PM
To: [email protected] >> EPICS Tech Talk
Subject: AreaDetector bindings and RBV propagation

I have completed a basic AreaDetector module for my camera and am working on adding enhancements.  Presently, I am attempting to add readback of acquisition status.  I am unfamiliar with the normal operations of the RBV PVs, but tried manipulating one for practice.  The sequence of events is:
1. Start IOC.
2. Caget $(P)$(R)DetectorState_RBV.  It is idle.
3. Run acquisition command.
4. Caget $(P)$(R)DetectorState_RBV.  It is idle.
5. Caput $(P)$(R)GetStatus  1.  PV and function are detailed below.  Initially reported value is 0, as expected.
6. Caget $(P)$(R)DetectorState_RBV.  It is "Correct" (numeric value 3, as expected from GetStatus code).
7. Caput $(P)$(R)DetectorState_RBV 2.
8. Caget $(P)$(R)DetectorState_RBV.  It is "Readout" (as expected from ADBase.template, numeric value 2).
9. Caput $(P)$(R)GetStatus 1.  Initially reported value is 3, not 2 as would be expected from step 8.
10. Caget $(P)$(R)DetectorState_RBV.  It is "Readout" (numeric value 2), not 3 as would be expected from step 9.

The Get Status code is

if (function == detector_get_status_)
    {
      printf("Received SDGetStaus command.\n");
      // XXX Does putting a Get make the set take effect?
      getIntegerParam(ADStatus, &det_status);
      printf("Detector status before set is %i.\n", det_status);
      setIntegerParam(ADStatus, 3);
    }

And the GetStatus record is:
record(longout, $(P)$(R)GetStatus)
{
        field(DTYP, "asynInt32")
        field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))SDGETSTATUS")
}

Why are the values not propagating between parameter library and PVs, and how does one update these readback value PVs?

Thank you,

Iain Marcuson.

References:
AreaDetector bindings and RBV propagation Iain Marcuson
RE: AreaDetector bindings and RBV propagation Mark Rivers

Navigate by Date:
Prev: Question about Edm dynamic display zone's fill color according to PVs lzf neu
Next: Re: CSS PyDev - capturing mouse event Kasemir, Kay
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: AreaDetector bindings and RBV propagation Mark Rivers
Next: RE: AreaDetector bindings and RBV propagation Iain Marcuson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024