Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: RE: Writing mbbo/mbbi text labels using asynPortDriver/areaDetector
From: "Mark Rivers" <rivers@cars.uchicago.edu>
To: <tom.cobb@diamond.ac.uk>, "Eric Norum" <wenorum@lbl.gov>, "Marty Kraimer" <mrkraimer@comcast.net>
Cc: tech-talk@aps.anl.gov
Date: 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: tom.cobb@diamond.ac.uk [mailto:tom.cobb@diamond.ac.uk] 
Sent: Tuesday, January 04, 2011 8:29 AM
To: Mark Rivers
Cc: tech-talk@aps.anl.gov
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
 





References:
Writing mbbo/mbbi text labels using asynPortDriver/areaDetector tom.cobb

Navigate by Date:
Prev: PV Mapping Using Java Annotations Mitch McCuiston
Next: RE: MOXA terminal server emma.shepherd
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: Writing mbbo/mbbi text labels using asynPortDriver/areaDetector Maren Purves
Next: record STAT = SCAN John Dobbins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·