Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Tue, 20 Mar 2018 12:38:33 +0000

Hi Mark,

Indeed the asyn module is widely used in situations where the client is not EPICS device support.  For example, it is used as the interface between plugins in areaDetector, which is independent of records.  It is also used between motor drivers and underlying drvAsynIPPort or drvAsynSerialPort drivers, which are again independent of records.

The association of a particular string in drvUser->create() with a particular asyn interface (asynInt32, asynFloat64, asynOctet) is not an inherent part of asyn.  The same string could be used for multiple interfaces for a driver written using the C API in asyn.  I imposed that restriction in asynPortDriver to simplify the parameter library.  The parameters are each identified by a unique string, and each has a single associated interface.  The generic asyn device support (e.g. devAsynInt32.c) is not restricted to use with asynPortDriver, so must not impose restrictions that a drvUser->create() string is associated with a specific asyn interface.

There are 2 additional arguments to drvUser->create:

asynStatus (*create)(void *drvPvt,asynUser *pasynUser,
        const char *drvInfo, const char **pptypeName,size_t *psize

These are not used by the standard asyn device support, e.g. devAsynInt32:

        status = pasynDrvUser->create(drvPvt,pasynUser,pPvt->userParam,0,0);

In all drivers that I know of drvUser->create() results in the driver setting pasynUser->reason to an integer value to indicate what parameter is involved.

The 2 additional arguments are intended for situations where pasynUser->reason is not sufficient.  They allow the driver to communicate additional information through pasynUser->drvUser.  The pptypeName and psize arguments allow getting information back from the driver to let the client properly interpret pasynUser->drvUser.

In principle you could use the pptypeName argument to send the type information to the driver.  The problem is that this would require
- Modifying device support
- Modifying asynPortDriver
- Breaking the specification of the drvUser interface which specifies the opposite direction for this argument

I think it would be simpler to just embed the type information in your drvUser->create() string.

Mark

________________________________
From: Mark Davis <[email protected]>
Sent: Tuesday, March 20, 2018 6:24 AM
To: [email protected]; Mark Rivers
Subject: Re: Asyn getting DTYP field in drvUserCreate()

HI Mark,

We are working on a newer version of an asynPortDriver-based driver that
creates the asyn parameters during the call to drvUserCreate() based on
the string passed to it, which means that the string must include the
asynType for the new parameter.  This avoids the need to include the
list of parameters as part of the code (requiring a unique version of
the driver for each type of device it can talk to).

This works well, but it means a bit of redundancy since the asynType is
specified both in the DTYP and the INP/OUT string for the record.

I believe the documentation for the asyn module (and emails from you on
this list ) state that the asyn module is designed so that it can be
used by clients other than the EPICS record interface, so there is the
issue of whether or not it would even be possible to provide this
information in a manner that would not depend on what the client is.

Obviously, the question as stated ("What is the DTYP" value in the
record?") assumes the call is on behalf of an EPICS record, so the
answer is NO.  On the other hand, I also assume that, whatever the
client is, it has to specify which of the asynType interfaces it is
using to communicate with the asyn layer, so the question(s) could be
restated as:  "Is the asynType known before the call to drvUserCreate(),
and if so, could it be make available to the drvUserCreate() function
(either as part of the information in the asynUser struct or a function
that drvUserCreate() can call)?"

Mark Davis
NSCL/FRIB Controls Staff Engineer
[email protected]

On 3/19/2018 6:11 PM, Mark Rivers wrote:
> Hi Konrad,
>
> I can't think of a way for the driver to know the value of DTYP.  Of course you specify both the drvUser string and the datatype when you call createParam() so your driver knows the datatype that a particular drvUser string will be using.  Why do you need to know the DTYP?
>
> Mark
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf
>> Of Konrad, Martin
>> Sent: Monday, March 19, 2018 8:39 AM
>> To: EPICS Tech Talk <[email protected]>
>> Subject: Asyn getting DTYP field in drvUserCreate()
>>
>> Hi,
>> I'm wondering if there is a way I can get access to the DTYP field of
>> the record from asynPortDriver's drvUserCreate method.
>>
>> Once createParam() has been called in drvUserCreate() I can get the type
>> by calling getParamType() but how do I get access to this information in
>> drvUserCreate()?
>>
>> It seems like other drivers are duplicating this information into the
>> INP/OUT field (see e.g. [1]). I'm wondering if there is a more elegant
>> way to do this.
>>
>> Thanks a lot,
>>
>> Martin
>>
>> [1]
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__controls.diamond.ac.uk_downloads_support_aravisGigE_0-2D3-2D&d=DwIFAg&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=ye8rwKce1N2smS_Qv4NJE7cxkvL2pAyhv01q1CorLNY&s=4dEd2vIEg8lp5k3Z8SyaW9RUE-YJbhcHHYpmwmR0EXg&e=
>> 5dls5/documentation/doxygen/aravisCamera_8cpp_source.html#l00326
>>
>> --
>> Martin Konrad
>> High Performance Controls Team Leader
>> Facility for Rare Isotope Beams
>> Michigan State University
>> 640 South Shaw Lane
>> East Lansing, MI 48824-1321, USA
>> Tel. 517-908-7253
>> Email: [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System