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 <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 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 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 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 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, |