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]" <[email protected]>
Date: Tue, 28 Jan 2014 18:05:39 +0100
Hi Tim,
this is the test I made, so the problem is not affecting my database.

Thank you very much,
Matteo
Ing. Matteo Pardi
CAEN SpA - R&D Software Division
Via Vetraia, 11 - 55049 Viareggio (LU)- ITALY
Tel. +39 0584 388 398 - Fax +39 0584 388 959
[email protected] - www.caen.it
----------------------------------------------
*****************************************************************************************************************************************************
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 28/01/2014 17:43, Mooney, Tim M. ha scritto:
Hi Matteo,

It's hard for me to tell, because I don't understand the situation you're describing message exactly enough.

But there is a simple test:
In one window or x terminal, do this:
    camonitor record.VAL
In a separate window, do this repeatedly:
    caget record.VAL

While these guys are running, write a new value to the hardware from your separate, non-EPICS software.
If you see the new value in both windows, your database doesn't have the problem I was worried about.

Tim

From: [email protected] [[email protected]] on behalf of Matteo Pardi [[email protected]]
Sent: Tuesday, January 28, 2014 3:36 AM
To: [email protected]
Subject: Re: PV for both input AND output

Hi Tim,
thanks for your suggestion.
I made this change because when someone writes a new value into my hardware, it is designed to send to everyone connected this new value, so the I/O will be processed, as an event, soon after. This particular hw behaviour force me to do this 3 records change, otherwise I would incur in unwanted loops.
I tried this by writing with another software into the hardware and now I correctly see the modification into EPICS.

Do you agree now, or am I missing something?

Matteo Pardi

Ing. Matteo Pardi
CAEN SpA - R&D Software Division
Via Vetraia, 11 - 55049 Viareggio (LU)- ITALY
Tel. +39 0584 388 398 - Fax +39 0584 388 959
[email protected] - www.caen.it
----------------------------------------------
*****************************************************************************************************************************************************
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 27/01/2014 18:38, Mooney, Tim M. ha scritto:
Hi Matteo,

You might want to keep that fourth record, even though it doesn't seem useful right now.  With your modification, a new value written by record_Sync will not be posted, because the only way to get a VAL field posted is to process the record, but the record is scan-disabled by record_Sync because you don't want to write to hardware.  As a result, clients that do a "get" will see the new value, but clients monitoring the record's VAL field won't be notified that it has changed.

Tim Mooney

________________________________________
From: [email protected] [[email protected]] on behalf of Matteo Pardi [[email protected]]
Sent: Monday, January 27, 2014 4:11 AM
To: [email protected]
Subject: Re: PV for both input AND output

Hi Mark,
after a lot of reading I understood your proposed solution, I tried it
and (obviously ;)) it works!
I also made a change into it because it is enough to me to use 3 records
instead of 4.
I made the database look like this:

record( ao, "record")
{
         field( SDIS, "record_Sync.PACT")
         field( OUT, "@RECORD")
}
record(ai, "record_RBV")
{
         field( INP,  "@RECORD")
         field( SCAN, "I/O Intr")
         field( PINI, "YES")
         field( FLNK, "record_Sync")
}
record(ao, "record_Sync")
{
         field( DOL,  "record_RBV NPP")
         field( OMSL, "closed_loop")
         field( OUT,  "record PP")
}

I hope I didn't do anything wierd in EPICS "coding conventions".

Many thanks to everyone for the help,
Matteo

Ing. Matteo Pardi
CAEN SpA - R&D Software Division
Via Vetraia, 11 - 55049 Viareggio (LU)- ITALY
Tel. +39 0584 388 398 - Fax +39 0584 388 959
[email protected] - www.caen.it
----------------------------------------------
*****************************************************************************************************************************************************
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 18:13, Mark Rivers ha scritto:
Hi Matteo,

You showed me an example about an asynchronous record, but what if I have a synchronous one?
There is nothing in my example that assumes an asynchronous record.  It is using the "asyn" device support, but that works with both asynchronous and synchronous records.

When you say
FileNumber is the output record that the user sees.
what do you mean with "sees"?
I just mean FileNumber is the record that would normally be exposed on the user GUI.  The FileNumber_write and FileNumber_sync records are for "internal" use to implement the logic, and would normally not be exposed on the user GUI.  The FileNumber_RBV would also be exposed to the user, and should always reflect the actual state of the hardware.

Mark


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

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




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
RE: PV for both input AND output Mark Rivers
Re: PV for both input AND output Matteo Pardi
RE: PV for both input AND output Mooney, Tim M.
Re: PV for both input AND output Matteo Pardi
RE: PV for both input AND output Mooney, Tim M.

Navigate by Date:
Prev: RE: PV for both input AND output Mooney, Tim M.
Next: epicsTime::strftime Pearson, Matthew R.
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 Mooney, Tim M.
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 
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 ·