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  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Accessing Record fields from asyn driver
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: 'Ralph Lange' <ralph.lange at gmx.de>, 'Torsten Bögershausen' <torsten.bogershausen at ess.eu>, "Johnson, Andrew N." <anj at anl.gov>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Fri, 12 Mar 2021 17:57:20 +0000

Ralph,

 

Andrew has suggested naming the interface asynMetaParam.  Does this seem OK? 

 

Torsten is working on it.

 

Ø  For asynMetadata the keys could be “egu”, “low_alarm”, “high_alarm”, “min_value”, “max_value”, etc.

 

I was thinking that an issue we have never resolved is telling an asyn port driver when it should do callbacks: only when a value has changed, or every time it reads a value.  asynPortDriver currently only does callbacks when a value changes.  This is the desired behavior in most cases, but there definitely cases where we want a callback on every new reading.  For example when asynInt32Average device support is being used to average values from an ADC, etc.  For drivers to do that now requires a kluge: set the parameter to a garbage value and then to the correct value before doing the callbacks.  That forces the callback to occur.

 

This new interface could be used to communicate to the driver that callbacks should be done on all reads.  This could be done with a new info tag e.g. “asyn:CALLBACK_ALWAYS”.   It could also be done by propagating the MDEL field of the record to the driver.  But that is probably not such a good idea since it mixes the behavior of the driver with the behavior of the record.

 

Mark

 

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: Monday, March 1, 2021 8:27 AM
To: 'Ralph Lange' <ralph.lange at gmx.de>; 'Torsten Bögershausen' <torsten.bogershausen at ess.eu>
Cc: tech-talk at aps.anl.gov
Subject: RE: Accessing Record fields from asyn driver

 

OK, I was too hasty in my reply to Torsten!

 

We could create a new asynMetadata interface, similar to asynOption.

 

typedef struct asynMetadata {

    asynStatus (*writeString)(void *drvPvt, asynUser *pasynUser,

                              const char *key, const char *val);

    asynStatus (*readString)(void *drvPvt, asynUser *pasynUser,

                             const char *key, char *val, int sizeval);

    asynStatus (*writeInt32)(void *drvPvt, asynUser *pasynUser,

                             const char *key, epicsInt32 val);

    asynStatus (*readInt32)(void *drvPvt, asynUser *pasynUser,

                            const char *key, epicsInt32*val);

    asynStatus (*writeFloat64)(void *drvPvt, asynUser *pasynUser,

                               const char *key, epicsFloat64 val);

    asynStatus (*readFloat64)(void *drvPvt, asynUser *pasynUser,

                              const char *key, epicsFloat64 *val);

} asynMetadata;

 

There would be well-defined, but extensible, values for “key”.  With asynOption on serial devices key can be “baud”, “parity”, etc.  For asynMetadata the keys could be “egu”, “low_alarm”, “high_alarm”, “min_value”, “max_value”, etc.

 

Mark

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Ralph Lange via Tech-talk
Sent: Monday, March 1, 2021 8:02 AM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Accessing Record fields from asyn driver

 

Hi Torsten,

 

In the context of the OPC UA Device Support, I have had this requirement coming up, and I think it would be worthwhile doing a design for adding this functionality.

The next important step there would be thinking about a proper definition and an easy, generic yet comprehensive way of configuring this mapping.

Polling for changes or subscribing to metadata is probably too resource expensive (at least in the OPC UA case), but reading the metadata on (re)connection should be feasible.

 

If you have input to this, I'd be happy to hear about it.

 

Cheers,
~Ralph

 


References:
Accessing Record fields from asyn driver Torsten Bögershausen via Tech-talk
Re: Accessing Record fields from asyn driver Ralph Lange via Tech-talk
RE: Accessing Record fields from asyn driver Mark Rivers via Tech-talk

Navigate by Date:
Prev: Re: Beatnik RTEMS4.10.2 vmeTsi148 ISR: ERROR: no handler registered Matt Rippa via Tech-talk
Next: SEQ Record Question Manoussakis, Adamandios via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
Navigate by Thread:
Prev: Re: Accessing Record fields from asyn driver Torsten Bögershausen via Tech-talk
Next: Job Opportunity - Control Systems Group Leader Forestiero, Suzanne via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 12 Mar 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·