Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 24 Apr 2002 15:57:49 +0200

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System