Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Mon, 10 Jan 2011 18:30:36 -0600

Tom,

One way to do this would be to add a new function to the asynInt32 and
asynUInt32Digital interfaces.  These are the interfaces that support bi,
bo, mbbi, mbbo, and mbbi records.

The new function could be something like

asynStatus (*getEnumStrings)(void *drvPvt, asynUser *pasynUser, 
                             epicsInt32 maxStrings, epicsInt32
maxLength, 
                             epicsInt32 *numStrings, char **strings);

This function would need to be added at the end of the current list of
functions in the asynInt32 (and asynUInt32Digital) interface.
asynInt32Base.c would provide a dummy implementation of this function
that returns an error.  If a driver provides no implementation of the
function then the dummy implementation is used.  

EPICS device support would call this function in init_record.  If the
function returns an error it does nothing.  If it does not return an
error then it copies the strings to the record.

A potential problem I see with this concerns existing drivers that we
don't want to force people to modify.  This mechanism assumes that when
a driver allocates the asynInt32 structure (which contains the function
pointers) it will zero that structure.  That way the functions beyond
those that the driver fills in with valid addresses will be NULL, which
can then be detected by asynInt32Base->initialize().  If the driver does
not zero the structure then the location of the new function pointer
could be garbage, and the IOC will crash when device support attempts to
call the function.

All drivers that I have looked at do zero the structure before they fill
it in, either by using static variables or by using calloc().  But do we
want to require this?  It is probably a good idea to require it, so that
asyn interfaces are extensible.

Thoughts?

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Tuesday, January 04, 2011 8:29 AM
To: Mark Rivers
Cc: [email protected]
Subject: Writing mbbo/mbbi text labels using asynPortDriver/areaDetector

Hi all,

I've been writing an areaDetector driver that will support the majority
of generic GigE Vision cameras, and I've run into a problem. A number of
the parameters supported by the driver are enumerations that vary from
camera to camera. For instance, the TriggerSource enum on one camera may
be ["Internal", "External"], or ["Line1", "Line2", "FixedRate",
"Software"] on another. I could create a database for each camera
containing the correct labels for each parameter, but it would be a lot
neater to get the mbbo/mbbi record to query asynPortDriver for a list of
strings at startup.

Does anyone have any ideas on the neatest approach on this, and some
pointers on where to make the modifications?

Thanks,
Tom Cobb,
Diamond Light Source Ltd.
Diamond House
Harwell Science and Innovation Campus
Didcot
Oxfordshire
OX11 0DE
Tel +44 (0) 1235 778582

-- 
This e-mail and any attachments may contain confidential, copyright and
or privileged material, and are for the use of the intended addressee
only. If you are not the intended addressee or an authorised recipient
of the addressee please notify us of receipt by returning the e-mail and
do not use, copy, retain, distribute or disclose the information in or
attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual
and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any
attachments are free from viruses and we cannot accept liability for any
damage which you may sustain as a result of software viruses which may
be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in
England and Wales with its registered office at Diamond House, Harwell
Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System