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
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.
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Tuesday, January 04, 2011 8:29 AM
To: Mark Rivers
Subject: Writing mbbo/mbbi text labels using asynPortDriver/areaDetector
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?
Diamond Light Source Ltd.
Harwell Science and Innovation Campus
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
- Writing mbbo/mbbi text labels using asynPortDriver/areaDetector tom.cobb
- Navigate by Date:
PV Mapping Using Java Annotations Mitch McCuiston
RE: MOXA terminal server emma.shepherd
- Navigate by Thread:
Re: Writing mbbo/mbbi text labels using asynPortDriver/areaDetector Maren Purves
record STAT = SCAN John Dobbins