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: Matteo Pardi <[email protected]>
To: [email protected]
Date: Thu, 16 Jan 2014 17:19:52 +0100
Hi Mark,
thank you to your precious explanation, I still have a doubt about it.
You showed me an example about an asynchronous record, but what if I have a synchronous one?
Do I have the same 4 records used for 1 item?

When you say

FileNumber is the output record that the user sees.

what do you mean with "sees"?
Why the "$(P)$(R)FileNumber_write", the "$(P)$(R)FileNumber_RBV" and the "$(P)$(R)FileNumber_Sync" are not seen by the user? 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?

Thank you for your patience,
Matteo

*****************************************************************************************************************************************************
The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and destroy all copies of the original message.

Il 16/01/2014 16:52, Mark Rivers ha scritto:
Hi Matteo,

What you propose is possible if the device support is written to do that.

Most existing device support does not.  For example, the standard asyn device support for output records attempts to read the value from the hardware once at iocInit.  If that succeeds then the output record value is set to match the hardware, which supports "bumpless reboots".  However, if the value changes after that for some reason other than the output record changing it, then the output record will not update to reflect that change.

The traditional way around this is to do the following in a database:

record(longout, "$(P)$(R)FileNumber")
{
     field(PINI, "YES")
     field(OUT, "$(P)$(R)FileNumber_write PP")
     field(VAL, "1")
}

record(longout, "$(P)$(R)FileNumber_write")
{
     field(SDIS, "$(P)$(R)FileNumber_Sync.PACT")
     field(DISV, "1")
     field(DTYP, "asynInt32")
     field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))FILE_NUMBER")
}

record(longin, "$(P)$(R)FileNumber_RBV")
{
     field(DTYP, "asynInt32")
     field(INP,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))FILE_NUMBER")
     field(SCAN, "I/O Intr")
     field(FLNK, "$(P)$(R)FileNumber_Sync")
}

record(longout, "$(P)$(R)FileNumber_Sync")
{
     field(DOL,  "$(P)$(R)FileNumber_RBV NPP")
     field(OMSL, "closed_loop")
     field(OUT,  "$(P)$(R)FileNumber PP")
}

FileNumber is the output record that the user sees.  FileNumber_RBV is a readback (input) record.  It will change if the hardware changes for any reason.  If the RBV changes then it will write the new value into FileNumber.  That will NOT write the value to the hardware again if it being written because of a callback to _RBV.

I am thinking about writing a new type of device support for asyn output records that would handle this in device support, so one would not need this database logic.

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Matteo Pardi
Sent: Thursday, January 16, 2014 9:34 AM
To: [email protected]
Subject: PV for both input AND output

I have a question related to the in/out PVs used in an IOC .
Can I create a process variable which will have a callback to read data,
and a callback to write data?

Let's make, for example, we have an "ao" PV, which the IOC uses to write
the data into the hardware.
The database entry loaded in the IOC will be something like

record( stringout, "pVariable")
{
      field( DESC, "this is an example process variable")
      field( DTYP, "blabla Item")
      field( OUT, "@pVariable");
}

This PV will be handled from the EPICS framework by calling the callback
"write_ao", every time a client writes the "1" value in it. So in the
"write_ao" function we'll provide the code necessary to write the data
into the hardware too. Well, if a client write the value "1" in
pVariable, the EPICS internal structure variable is up to date (the one
which is the formal parameter with "aoRecord*" type in the callback),
and the hardware has received the write command (both show the "1" value).
Then we connect a different standalone software (independent to EPICS)
to the hardware , and we change the pVariable to "2".
This variable is an "ao", so it has only one callback for write, the
"write_ao" callback, and there is no way to notify it the pVariable
value has been changed from the outside. So the pVariable value in the
hardware (and in the standalone software) is "2", but EPICS will show
"1", because no read have happened.

On the other side, if we had created an "ai" process variable, which has
the "read_ai" callback to read data, we have no "write_ao" callbacks to
write data, in fact is forbidden to write an input process variable.

So my question still remains the same: how to use a single process
variable, to both read and write, if I have only one callback, and I
need to read and write item values to the hardware, not only when I
write a new value.
Maybe I missed something in the EPICS documentation, but I really can't
find anything about this question anywhere.
So the only solution that came to my mind was to use two different PVs,
one for read and one for write, but it seems not to be the right one.

Thank you in advance,
Matteo



Replies:
RE: PV for both input AND output Mark Rivers
RE: PV for both input AND output Emmanuel Mayssat
References:
PV for both input AND output Matteo Pardi
RE: PV for both input AND output Mark Rivers

Navigate by Date:
Prev: Re: garbage in zero length arrays Ralph Lange
Next: RE: garbage in zero length arrays Mezger Anton Christian
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 Mark Rivers
Next: RE: PV for both input AND output Mark Rivers
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 ·