Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Thu, 23 Feb 2012 16:00:20 +0000

Hi Lana,

OK, I understand better now what you are asking and why.

But I do need one further clarification.  You said:

> Currently for each device support based on asyn, we have a dbd file. 
> So currently i have one dbd file for the timing card, one dbd file for the FlexRio family card.

Please explain what is in the dbd file for the timing card and the dbd file for the FlexRio family card?  Have you written custom device support based on asyn?  Or have you just written a driver, and are using the standard asyn device support that comes with asyn?

I always do the latter (for standard EPICS records), i.e. just use standard asyn device support.

In that case the dbd file for my driver typically contains just one line like this:

#####
registrar(drvDac128VRegister)
#####

Note that it does not define any device support, just the driver registration commands.  Then when my application is built it just includes "asyn.dbd", which in turn includes "devEpics.dbd", which defines the standard asyn device support.

I understand that if the user tries to connect a record with device support that uses an asyn interface that is not supported in your driver they will get an error.  Unfortunately I don't think there is an easy solution to that problem.  Let's assume that a user builds an IOC application that wants to use both your timing card and a TCP/IP device of some sort.  In that case they will NOT need asynOctetWrite device support to talk to your timing card, but they WILL need it to talk to the TCP/IP device. 

There is no way specify that the asynOctetWrite device support can only be used with some drivers (e.g. the TCP/IP driver) and not with other drivers (e.g. your timing card).  Either that device support is loaded or it is not.

I think you will just need to educate users that they can only load device support for interfaces that are supported by a particular driver.  The asynManager does produce a pretty informative and specific error message if they do make that mistake, as you showed in your message.

Note that the choice of what dbd files to load is made when the IOC application is built, not when the driver is compiled.  So if you are SURE that your IOC application will never need to use any drivers that use the asynOctetWrite device support, then you can make a custom dbd file that does that (by not including asyn.dbd or devEpics.dbd, but by using only a specific subset of the files that they include or things they define).  But that is a lot of work, hard to maintain, and I would not recommend it.

Cheers,
Mark

________________________________________
From: Abadie Lana [[email protected]]
Sent: Thursday, February 23, 2012 6:12 AM
To: Mark Rivers; [email protected]
Subject: RE: Best pratices for compiling dbd files for asyn base device support

Hi Mark
Yes sorry I was not clear and i would like to say that I'm not a driver developer (i'm database)- so maybe my questions will sound stupid....
So let me reformulate.
Currently for each device support based on asyn, we have a dbd file. So currently i have one dbd file for the timing card, one dbd file for the FlexRio family card.
Then i parse this dbd file, to get the proper relationship between record type and DTYP and device support to suggest to the user the right possible DTYP according to his/her config.

The problem - maybe it is a problem only for me - is in our case we include asyn.dbd in building the dbd file, except that in my case the timing card does not support AsynOctet for instance. So if a user declares the following PV
record (stringout,"myPV")
{
  field(DTYP, "asynOctetWrite")
        field(OUT, "@asyn(S0,1)")
       field(SCAN,"Passive")
}
The db file  is OK from EPICS point of view. The DTYP is a valid one because it is found in the dbd file. But the driver does not support it and then I  can see in the IOC console

In the IOC console it prints a message
myPV devAsynOctet::initCommon interface asynOctet not found

This command explains that this device supports AsynInt32 and AsynInt32Array which are correct
iocVAC-SR-PCF0CORE> asynReport 10 S0
S0 multiDevice:Yes canBlock:No autoConnect:Yes
    enabled:Yes connected:Yes numberConnects 1
    nDevices 1 nQueued 0 blocked:No
    asynManagerLock:No synchronousLock:No
    exceptionActive:No exceptionUsers 0 exceptionNotifys 0
    interfaceList
        asynCommon pinterface 0x7f8e0f464df0 drvPvt 0x1d11370
        asynDrvUser pinterface 0x7f8e0f464e10 drvPvt 0x1d11370
        asynInt32 pinterface 0x7f8e0f464e40 drvPvt 0x1d11370
        asynInt32Array pinterface 0x7f8e0f464e80 drvPvt 0x1d11370
    addr 1 autoConnect Yes enabled Yes connected No exceptionActive No
    exceptionActive No exceptionUsers 0 exceptionNotifys 0
    blocked No

So I wanted to avoid this situation by for instance to have in the dbd of the device support (e.g. timing card) only the right deviceXXX line.
And related to that, if this deviceXXX can be generated using the code  itself?

Thanks for your feedback and let me know if i'm not clear

Lana

-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: 22 February 2012 18:10
To: Abadie Lana; [email protected]
Subject: RE: Best pratices for compiling dbd files for asyn base device support

Hi Lana,

I am not sure I understand your suggestion.

> Currently when a driver is using EPICS device support via asyn, it has
> these lines in the Makefile XX_DBD += base.dbd XX_DBD += asyn.dbd

Actually that statement is not really correct.  The correct statement is:

"Currently when an APPLICATION is using EPICS device support via asyn, it has these lines in the Makefile"

There is a big difference.  An application may load many drivers.  Some will support a specific asyn interface (e.g. asynOctet, asynInt32, etc.) and some will not.

> It is fine when your driver supports all of them, but not if your driver supports part of them.

That is not true.  There is no harm in loading all of the device support that is in devEpics.dbd, which is included by asyn.dbd.  It just adds a few kB to your application.  It does not lead to any problems if there happen to be no drivers in your application that supports a particular record type or asyn interface.  If you are having problems because your driver does not support a particular interface, then something is wrong with the way you are building your application or something.  If you are receiving an error please include it in your message.

asyn.dbd contains the following:

###############################
registrar(asynRegister)
registrar(asynInterposeFlushRegister)
registrar(asynInterposeEosRegister)
#
# The following ties this to EPICS records.
# Applications which wish to use ASYN without EPICS # records can comment out the following lines.
include "asynRecord.dbd"
include "devEpics.dbd"
driver(drvAsyn)
###############################

If you really want to exclude things from asyn.dbd (which as I said, I don't see any reason to do) then simply don't include asyn.dbd, just add whatever lines from asyn.dbd that you want in your application's dbd file.  For example include all lines above except devEpics.dbd, etc.

Mark

________________________________________
From: [email protected] [[email protected]] on behalf of Abadie Lana [[email protected]]
Sent: Wednesday, February 22, 2012 4:41 AM
To: [email protected]
Subject: Best pratices for compiling dbd files for asyn base device support

Hi all
I would like to collect some feedback on the best things to include proper DTYP information in the dbd file when using asyn.
Currently when a driver is using EPICS device support via asyn, it has these lines in the Makefile XX_DBD += base.dbd XX_DBD += asyn.dbd

This will result in a dbd for the driver which includes all the combination record type/DTYP from asyn (referring lines to device(XXX)). It is fine when your driver supports all of them, but not if your driver supports part of them.
So one idea would be to modify the asyn.dbd and comment the include devEpics and add another dbd which manually lists the supported interfaces  per  device support.
Does it sounds reasonable ? any other feedback?
Thanks
Lana

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System