Re: PV for both input AND output

[Matteo Pardi <m.pardi@caen.it>]

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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Matteo Pardi
> Sent: Thursday, January 16, 2014 9:34 AM
> To: tech-talk@aps.anl.gov
> 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