Re: Accessing Record fields from asyn driver

[Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>]

That's so nice, thanks Ralph and Mark.

Could this be something for the codeathon ?



On 2021-03-01 15:26, Mark Rivers wrote:
> 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