EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Asyn driver access to PV fields.
From: "Mark Rivers" <[email protected]>
To: "Marty Kraimer" <[email protected]>, <[email protected]>
Cc: [email protected]
Date: Fri, 20 Feb 2009 08:05:33 -0600
Marty,
 
> What about adding a new method to asynUInt32Digital?

> Then change devAsynUInt32Digital so that it supports the new method.
> Also change  asynUInt32DigitalBase so that it implements the new method
> by returning failure. Thus no existing driver will fail.

I was thinking of adding doing it using the asynOctet interface, but a new method is probably cleaner.  It needs to be added to asynInt32 as well, because mbbo and mbbi are supported on both asynInt32 and asynInt32Digital.
 
However, there may be a quick solution to Brian's problem, since I suspect it is related to areaDetector?
 
In the databases for areaDetector there are default enum strings for records like TriggerMode, for example from ADBase.template
record(mbbo, "$(P)$(R)TriggerMode")
{
   field(PINI, "1")
   field(DTYP, "asynInt32")
   field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))TRIGGER_MODE")
   field(ZRST, "Internal")
   field(ZRVL, "0")
   field(ONST, "External")
   field(ONVL, "1")
}
 
Now some detectors will support a different set of trigger modes.  For example the Pilatus has a different set.  A very nice thing about the way that EPICS loads databases is that if after you load ADBase.template you load another file, say pilatus.template, you can define these enum strings for the record that is already loaded.  Here is the example from pilatus.template where I changed the enum strings for the same record already loaded in ADBase.template.
 
# We redefine the states for the TriggerMode records defined in ADBase.template
record(mbbo,"$(P)$(R)TriggerMode") {
    field(DESC,"Acquire mode")
    field(ZRVL,"0")
    field(ZRST,"Internal")
    field(ONVL,"1")
    field(ONST,"Ext. Enable")
    field(TWVL,"2")
    field(TWST,"Ext. Trigger")
    field(THVL,"3")
    field(THST,"Mult. Trigger")
    field(FRVL,"4")
    field(FRST,"Alignment")
}
 
Note that the only thing you cannot change is the record type for a record of the same name.
 
I already had to create the file pilatus.template because it also supports additional parameters (records) that are not in ADBase.template.  So if at database design time you know what the enum strings are for a particular specific piece of hardware you can customize the strings there.
 
I realize this is not as general as being able to read the strings from the driver itself, but it might solve the problem in this particular case.
 
Mark

 
________________________________

From: Marty Kraimer [mailto:[email protected]]
Sent: Thu 2/19/2009 4:00 PM
To: Mark Rivers
Cc: tieman; tech talk
Subject: Re: Asyn driver access to PV fields.



Mark Rivers wrote:
> Hi Brian,
>
> The asyn driver does not have access to the record.  The driver only
> talks to device support, and the device support talks to the record.
>
> I don't think you can do what you want using standard asyn device
> support.  But if you wrote your own device support for the mbbo record
> (based on the mbbo support in devAsyn/devAsynInt32.c for example)
> could use the asynOctet interface to query the driver for the enum
> string values during initRecord, and set those enum string values in the
> record.
>
> Mark
>
>
> -

What about adding a new method to asynUInt32Digital?

Then change devAsynUInt32Digital so that it supports the new method.
Also change  asynUInt32DigitalBase so that it implements the new method
by returning failure. Thus no existing driver will fail.


Marty




Replies:
Re: Asyn driver access to PV fields. tieman
References:
Asyn driver access to PV fields. tieman
RE: Asyn driver access to PV fields. Mark Rivers
Re: Asyn driver access to PV fields. Marty Kraimer

Navigate by Date:
Prev: Re: Asyn driver access to PV fields. Dirk Zimoch
Next: Re: Asyn driver access to PV fields. tieman
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Asyn driver access to PV fields. Marty Kraimer
Next: Re: Asyn driver access to PV fields. tieman
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·