Experimental Physics and
Industrial Control System

Kellee Summers <[email protected]> · Thu, 14 Aug 2014 13:03:32 -0700

Thank you Andrew, this may be the simplest solution, and it was easy to

test. It does do what I was looking for - since we're using just ao

records, this could do it for us.

On 08/14/2014 09:35 AM, Andrew Johnson wrote:

Hi Kellee,

The UDF field is not writeable; you're not doing anything wrong, I don't
know how Andrew Starritt achieved the effect he talked about.

If you want to put an ao record into a UDF alarm state, put a NaN value
into its VAL field:

tux% camonitor anj:ao
anj:ao                     <undefined> 0 UDF INVALID
anj:ao                     2014-08-14 11:12:36.438390 0
anj:ao                     2014-08-14 11:12:57.543911 nan UDF INVALID
anj:ao                     2014-08-14 11:13:33.298560 10
anj:ao                     2014-08-14 11:13:39.533800 nan UDF INVALID
anj:ao                     2014-08-14 11:13:44.165902 1

I triggered the above monitors like this:

tux% caput anj:ao 0
Old : anj:ao                         0
New : anj:ao                         0
tux% caput anj:ao NaN
Old : anj:ao                         0
New : anj:ao                         nan
tux% caput anj:ao 10
Old : anj:ao                         nan
New : anj:ao                         10
tux% caput anj:ao NaN
Old : anj:ao                         10
New : anj:ao                         nan
tux% caput anj:ao 1
Old : anj:ao                         nan
New : anj:ao                         1

Unfortunately this only seems to work for ao records; I thought it would
work on on ai records too but when I just tried that it didn't actually
change the record's alarm state. You can't use this approach for most of
the other record types either since their VAL fields don't have any
equivalent to a NaN value, but ao records may be all you need. Carl
Lionberger's device support might be the best way to do what you want
for other types, although I have never seen or tried it myself.

There are other ways to control the alarm severity of a record, for
example you can put the severity you want into the SIMS field, set SIMM
to 1 and write anything to the PROC field (or to the VAL field). This
will give you an alarm status of SIMM rather than UDF, but most CA
clients don't pay much attention to the alarm status so that might not
bother you.

HTH,

- (another) Andrew

On 08/14/2014 10:41 AM, Kellee Summers wrote:

Thanks Andrew,

I must have something wrong in my record definition or I am doing
something incorrectly, because that does not work for me from my C++
program.  I cannot even set the UDF to 1 with a caput.

     $ caget lbc:side0:dewarTemp.UDF
     lbc:side0:dewarTemp.UDF        0

     $ caput lbc:side0:dewarTemp.UDF 1
     Old : lbc:side0:dewarTemp.UDF        0
     New : lbc:side0:dewarTemp.UDF        0

Very simple record definition:

     record(ao, "lbc:side0:dewarTemp")
     {
             field(DESC, "LBC Blue temperature")
             field(EGU, "degrees K")
             field(HIHI, "215")
             field(HIGH, "210")
             field(LOW, "165")
             field(LOLO, "160")
             field(HHSV, "MAJOR")
             field(HSV, "MINOR")
             field(LSV, "MINOR")
             field(LLSV, "MAJOR")
     }

... Kellee

On 08/13/2014 05:45 PM, Andrew C. Starritt wrote:

Hi Kellee,

    I did something like what you are doing. The PV values are written to by a bash script.
If/when the source data did not exist or was stale I did I wrote 1 to the record's UDF field
which set it invalid.

       # Set undefined.
       #
       caput ${pvname:?}.UDF  1

where worked for me, i.e. set SEVR to INVALID and STAT to UDF (using base-3.14.12.3)
Regards

Andrew C. Starritt | Principal Controls Engineer | Australian Synchrotron
p: (03) 8540 4164 | f: (03) 8540 4200
[email protected] | www.synchrotron.org.au
800 Blackburn Road, Clayton, Victoria 3168

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Kellee Summers
Sent: Thursday, 14 August 2014 12:50 AM
To: Lionberger, Carl A.; [email protected]
Subject: Re: How to tag soft channels as undefined/disconnected

This sounds pretty simple and what I'm trying to do.  The problem is I
don't know how to do this part:  "sets the PV invalid"
How do you do that?  Is that just some kind of timeout on the processing?

Thanks for your help,
Kellee

On 08/13/2014 06:47 AM, Lionberger, Carl A. wrote:

For a project where I had a python program updating soft PVs, I wrote a timeout device support to use instead of the soft channel device support.  It times out and sets the PV invalid if a new value was not put to it within the timeout period since the last put. The C++ application just wouldn't put the value to the PV if the instrument data was invalid, and then the PV would go invalid without further action.  When valid data became available, the application would put it to the PV and the PV status would go normal again.

Carl

Carl Lionberger
Instrument Data Acquisition and Controls
Spallation Neutron Source
________________________________________
From: [email protected] <[email protected]> on behalf of Kellee Summers <[email protected]>
Sent: Tuesday, August 12, 2014 7:02 PM
To: [email protected]
Subject: How to tag soft channels as undefined/disconnected

Hi All,

We have set up an EPICS R3.14.12.4 database of pure software channels
(on a Linux system) so that we can use the alarm handler. The channel
values are being driven by a C++ software application that reads our
instrument data.   When the instrument data is stale (determined by an
out-of-date timestamp), I would like to
set the channels to UDF so that the alarm state is INVALID.

The SEVR and STAT alarm fields are non-modifiable.  I tried setting the
UDF field but it didn't give me a disconnected channel.

Do I need to modify the record processing?

Suggestions?

Thanks

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System