Experimental Physics and Industrial Control System
Hi Tom,
One of the limitations of asyn that you pointed out in your message last year has been that there was no way for drivers to set the values of enum values in records. In many cases this is not a problem, since the values are known in advance and can be set in the database files. But, as you described, some drivers need to set the enum values, for example a driver that works with several models of a device, and the choices vary with the model.
I have added a new asyn interface, asynEnum, to address this problem. This is the definition of the interface.
#########################################
#define asynEnumType "asynEnum"
typedef struct asynEnum {
asynStatus (*write)(void *drvPvt, asynUser *pasynUser,
char *strings[], int values[], int severities[], size_t nelements);
asynStatus (*read)(void *drvPvt, asynUser *pasynUser,
char *strings[], int values[], int severities[], size_t nelements, size_t *nIn);
asynStatus (*registerInterruptUser)(void *drvPvt, asynUser *pasynUser,
interruptCallbackEnumStrings callback, void *userPvt,
void **registrarPvt);
asynStatus (*cancelInterruptUser)(void *drvPvt, asynUser *pasynUser,
void *registrarPvt);
} asynEnum;
#########################################
I've modified the bi, bo, mbbi, and mbbo support in devAsynInt32 and devAsynUInt32Digital to query the enum strings from the driver in init_record, if the driver supports the interface. The driver can control not only the enum strings, but also the values and severities. The interface also supports callbacks, so drivers can notify device support at run-time when the enums have changed. For example, selecting a new ADC speed may change the available gains, etc. When enums are changed at run-time, older channel access clients like medm will not update those widgets immediately, but will if the window is closed and re-opened.
I have made the following additions to asynPortDriver to support this new interface:
An additional interface mask for using in calling the asynPortDriver constructor.
#define asynEnumMask 0x00002000
3 new functions:
virtual asynStatus readEnum(asynUser *pasynUser, char *strings[], int values[], int severities[], size_t nElements, size_t *nIn);
virtual asynStatus writeEnum(asynUser *pasynUser, char *strings[], int values[], int severities[], size_t nElements);
virtual asynStatus doCallbacksEnum(char *strings[], int values[], int severities[], size_t nElements, int reason, int addr);
asynPortDriver::readEnum and writeEnum base class implementations are dummy functions that just return asynError. Derived classes can implement these functions, typically just readEnum, for drivers that want to set enum values in init_record.
asynPortDriver::doCallbacksEnum handles callbacks to clients when enums change at run-time.
The asyn example/test programs, testAsynPortDriver and testErrors now demonstrate and test the readEnum and doCallbacksEnum functions.
The new interface is committed to Subversion:
https://svn.aps.anl.gov/epics/asyn/trunk/
It will appear in asyn R4-19 soon. Meanwhile anyone who has time to test it is encouraged to do so.
Thanks,
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
- Navigate by Date:
- Prev:
RE: Problem installing CA for QT Andrew Rhyder
- Next:
RE: labCa build fails on 64 bit Windows james.rowland
- 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:
FW: Problem installing CA for QT Andrew Rhyder
- Next:
Motor model 3 support for OMS MAXv-8000? Fong, Nia W.
- 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