Hej Mark,
may be I can think loudly ?
Today we have things like
getParamAlarmStatus(axisNo, function, &oldStat);
getParamAlarmSeverity(axisNo, function, &oldSevr);
And then I can do stuff lile this:
setParamAlarmStatus(axisNo, function, newStat);
setParamAlarmSeverity(axisNo, function, newSevr);
From my point of view, the driver has no clue about EPICS, this is a good thing.
Could we imagine a logic like this :
setParamMetaData(axisNo, function, “HIHI”, “100”);
setParamMetaData(axisNo, function, “EGU”, “deg C”);
I haven’t checked, if there is a nice way to implement this in device support,
but from a driver-writer-point-of-view it looks attractive.
BR
/Torsten
> On 1 mars 2021, at 14:43, Mark Rivers <rivers at cars.uchicago.edu> wrote:
>
> Hi Torsten,
>
>
> I think that 2 of the strengths of asyn are:
>
>
> - It is almost completely independent of EPICS at the driver layer. The only thing it uses it libCom.
>
> - It has well-defined single-purpose interfaces (asynInt32, asynFloat64, etc.) that write or read single values and return status information.
>
>
> If we were to add the metadata it would impact both of the above strengths.
>
>
> It seems to me that using "helper" records is not so bad to keep the drivers independent of knowledge of the details of EPICS records and to keep the interfaces clean.
>
>
> One of the weaknesses of asyn is that it is written in C, which makes it difficult to extend the interfaces in a backwards compatible manner. If it had been written in C++ this would be much easier.
>
>
> Mark
>
>
>
> ________________________________
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>
> Sent: Monday, March 1, 2021 7:27 AM
> To: tech-talk at aps.anl.gov; torsten.bogershausen at esss.se
> Subject: Accessing Record fields from asyn driver
>
> Folks,
>
> for some IO we have all logic in a PLC-ish system.
> If I take an ai record as an example, the the PLC
> does most of the work what we normally do in the record.
>
> Especially:
> The PLC "knows" values .EGU, HIGH, LOW, HIHI, LOLO
> (and probably others) because all the work is done inside the PLC
> program already.
>
> We want of cause an EPICS integration for those kind of devices
> (it could be as simple as a temperature sensor), it would be nice if we
> can use the values from the PLC for e.g. .EGU and the other fields.
> As is, without having to define the in the record database, with the
> risk of getting thme out of sync.
> And yes, we can query the PLC for all this kind of information.
>
> The asyn framework is really excellent in doing all the polling,
> but there is no way to "push" meta data into single record fields.
> (Unless I create a lot of helper-records, like a stringin to hold
> the .EGU field, and forward the value to the .EGU field of my ai
> record).
>
> Are there more people having the same issue ?
>
> Enhancing asyn with this functionality could be one option,
> as we have code here to influence the alarm state/severity.
>
> Any thoughts about this ?
>
> Thanks
> /Torsten
- References:
- Accessing Record fields from asyn driver Torsten Bögershausen via Tech-talk
- Re: Accessing Record fields from asyn driver Mark Rivers via Tech-talk
- Navigate by Date:
- Prev:
Re: Accessing Record fields from asyn driver Ralph Lange via Tech-talk
- Next:
RE: Accessing Record fields from asyn driver Mark Rivers 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
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Accessing Record fields from asyn driver Mark Rivers via Tech-talk
- Next:
Re: Accessing Record fields from asyn driver Ralph Lange 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
<2021>
2022
2023
2024
|