Bob Dalesio wrote:
>
> > (3) We could think about adding a new menuAlarmStat
> > value, to go along
> > with a non-OK severity whenever the value is clamped or
> > else rejected.
> > This is a little problematic because user interface
> > clients either have
> > the strings compiled into them or they cannot display
> > them properly.
> These strings are fetched over channel access - or should
> be. This should not be a problem. If it is, the applications
> put in knowledge that should not have been assumed and need
> to be fixed.
The applications that do *not* have the menuAlarmStat fields hard coded
have problems, like dm2k, although they do the right thing in principle.
They treat field STAT just like any other DBF_ENUM field, they fetch the
value in the native format which means for DBF_ENUM as a short, they get
the strings via DBR_GR_ENUM which has a hard coded limitation of 16
strings. Ask Jeff or take a look at db_access.h. I am talking about
R3.13.6, btw.
Clients can work around this by fetching the value with a DBR_STRING
request. This works because conversion is done by the server, so CA
limitations do not apply. This is avoided by most clients to reduce IOC
workload. Dm2k, for instance, does the CA level stuff in a generic way
not configurable by the user. Also, CA gives no hint to the client that
there are more that the hard coded 16 states for this ENUM to be
expected. So the client cannot know in advance that a certain value has
to be requested as DBR_STRING and not as DBR_ENUM. So clients need to
take special precaution to re-request the value as DBR_STRING in case it
gets a value greater than 15. Thus, it is correct that hard coding the
menuAlarmStat strings is not necessary.
Ben
- References:
- Re: AO: Drive Limit Mode Bob Dalesio
- Navigate by Date:
- Prev:
Re: NAN and [email protected] Marty Kraimer
- Next:
Re: strange behaviour of dbLoadtemplate Marty Kraimer
- 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: AO: Drive Limit Mode Bob Dalesio
- Next:
Re: AO: Drive Limit Mode Benjamin Franksen
- 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
|