EPICS Controls Argonne National Laboratory

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  <20142015  2016  2017  2018  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  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: PV for both input AND output
From: Emmanuel Mayssat <[email protected]>
To: Matteo Pardi <[email protected]>, EPICS mailing list <[email protected]>
Date: Thu, 16 Jan 2014 11:16:49 -0800


> You showed me an example about an asynchronous record, but what if I
> have a synchronous one?

async or sync is not relevant here.
What matters is that the output record is out of date (because the parameter was changed, but not through epics)
The update of that record is done with the input record which just fetched the correct parameter value from the hardware
The connection to that hardware can be sync or async since the processing/synchronization is done 100% in the EPICS database.

> Do I have the same 4 records used for 1 item?
Yes, a minimum of 4 records for (1 setpoint + 1 readback) which is one control parameter ( = 1 item?)
You can have more if the readback needs to be translated (i.e. not of the same type as the output record)

> When you say
> FileNumber is the output record that the user sees.
> what do you mean with "sees"?

The only one that appears in the GUI

> Why the "$(P)$(R)FileNumber_write", the "$(P)$(R)FileNumber_RBV" and the
> "$(P)$(R)FileNumber_Sync" are not seen by the user?

Exactly, the other ones are used for function-programming in the EPICS database
(That of course leads to proliferation of records which is not desirable, hence his suggestion of including this feature in asyn (i.e. c/c++ driver code))


> Will the fields specified in those records disable them from user view,
> and so if a user tries to query them with a client he will get an error?

No, but the user/operator is normally not playing with PVs.
He is only using the GUI to carry out his experiment.
Ultimately the user should care less about PV names, about PV naming convention, or even about what a PV is.

--
Emmanuel

References:
PV for both input AND output Matteo Pardi
RE: PV for both input AND output Mark Rivers
Re: PV for both input AND output Matteo Pardi

Navigate by Date:
Prev: RE: PV for both input AND output Mark Rivers
Next: RE: PV for both input AND output Emmanuel Mayssat
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: PV for both input AND output Matteo Pardi
Next: Re: PV for both input AND output Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·