Hi Lana,
> 1) How asyn knows the list of supported interfaces?
> Is there any standard C files/functions which declare them?
Do you mean the list of interfaces that a particular driver supports, or all of the asyn interfaces?
The interfaces that a particular driver supports are determined at run-time when the driver calls pasynManager->registerInterface() for each interface that it supports. It cannot be determined before the IOC boots. It would be unusual, but it is possible, that a driver would conditionally call registerInterface for a particular interface depending on some run-time decision, like what you specified in your configuration command.
The list of all interfaces is not fixed. There is a set of "standard interfaces" that come with asyn, but each is just determined by a header file and in some cases a C file that initializes the interface. That list is extensible, both in the future by asyn, and by the application developer who could add a new interface for a particular application.
> 2) I just want to be sure I understood something
> The following thing will not work
That will "work" in the sense that it will allow you to run those 2 drivers. But it will NOT prevent the problem you originally mentioned. Because you have this line:
device(stringout,INST_IO,asynSoOctetWrite,"asynOctetWrite")
you have now loaded the asynOctetWrite device support. Even though you loaded it in a file called nirio.dbd that will NOT prevent someone from loading a record with asynOctetWrite device support and trying to connect it to the nisync driver, i.e. the wrong driver and which does not support that interface.
The reason is that once that device support is loaded it can potentially be used with any driver that supports it, not just the one whose dbd file you happended to put it in.
Since this approach does not solve your original problem, I would suggest you just go back to loading asyn.dbd.
Cheers,
Mak
________________________________________
From: Abadie Lana [[email protected]]
Sent: Thursday, February 23, 2012 12:31 PM
To: Mark Rivers; [email protected]
Subject: RE: Best pratices for compiling dbd files for asyn base device support
Hi Mark
thanks for your patience and very useful feedback.
I have two more questions:
1) How asyn knows the list of supported interfaces? Is there any standard C files/functions which declare them?
2) I just want to be sure I understood something
The following thing will not work
a modified asynmodifed.dbd
driver(drvAsyn)
registrar(asynRegister)
registrar(asynInterposeFlushRegister)
registrar(asynInterposeEosRegister)
let's say one dbd file for nisync which includes only these lines
device(waveform,INST_IO,asynInt32ArrayWfIn,"asynInt32ArrayIn")
device(waveform,INST_IO,asynInt32ArrayWfOut,"asynInt32ArrayOut")
device(ai,INST_IO,asynAiInt32,"asynInt32")
device(aoi,INST_IO,asynAiInt32,"asynInt32")
registrar(nisyncDrvRegister)
and for nirio.dbd I would have these lines
device(ai,INST_IO,asynAiInt32,"asynInt32")
device(ai,INST_IO,asynAiInt32Average,"asynInt32Average")
device(ai,INST_IO,asynAiFloat64,"asynFloat64")
device(ai,INST_IO,asynAiFloat64Average,"asynFloat64Average")
device(ao,INST_IO,asynAoInt32,"asynInt32")
device(ao,INST_IO,asynAoFloat64,"asynFloat64")
device(mbbi,INST_IO,asynMbbiInt32,"asynInt32")
device(mbbi,INST_IO,asynMbbiUInt32Digital,"asynUInt32Digital")
device(mbbo,INST_IO,asynMbboInt32,"asynInt32")
device(mbbo,INST_IO,asynMbboUInt32Digital,"asynUInt32Digital")
device(mbboDirect,INST_IO,asynMbboDirectUInt32Digital,"asynUInt32Digital")
device(stringin,INST_IO,asynSiOctetWriteRead,"asynOctetWriteRead")
device(stringin,INST_IO,asynSiOctetRead,"asynOctetRead")
device(stringout,INST_IO,asynSoOctetWrite,"asynOctetWrite")
device(waveform,INST_IO,asynInt32ArrayWfIn,"asynInt32ArrayIn")
device(waveform,INST_IO,asynInt32ArrayWfOut,"asynInt32ArrayOut")
device(waveform,INST_IO,asynFloat32ArrayWfIn,"asynFloat32ArrayIn")
device(waveform,INST_IO,asynFloat32ArrayWfOut,"asynFloat32ArrayOut")
device(waveform,INST_IO,asynFloat64ArrayWfIn,"asynFloat64ArrayIn")
device(waveform,INST_IO,asynFloat64ArrayWfOut,"asynFloat64ArrayOut")
registrar("asynNirioDrvRegister")
and then
in my XXXApp/src/Makefile
I have
In the XXXApp/src/Makefile
# Include dbd files from all support applicationss
nisync-sample_DBD += base.dbd
nisync-sample_DBD += nisync-generalTime.dbd
nisync-sample_DBD += nisync.dbd
nisync-sample_DBD += asynmodfied.dbd
nisync-sample_DBD += nirio.dbd
# Add all the support libraries needed by this IOC
nisync-sample_LIBS += nisync-generalTime
nisync-sample_LIBS += asyn
nisync-sample_LIBS += nisync-epics
nisync-sample_LIBS += nirio
________________________________________
From: Mark Rivers [[email protected]]
Sent: Thursday, February 23, 2012 5:46 PM
To: Abadie Lana; [email protected]
Subject: RE: Best pratices for compiling dbd files for asyn base device support
Hi Lana,
OK, so it appears to me that you have not written any custom device support, you are just using the standard asyn device support.
You also said:
> Finally in our case an IOC can load many types of cards.
Then what I said previously then is still valid. Because your IOC can load a wide variety of cards, you should just load all of the standard asyn device support, i.e. asyn.dbd. That way users are free to load drivers for serial, TCP, etc. devices and all of the required device support will already be loaded.
It does mean that you will have to live with the problem you mentioned previously, a user loading a record with device support that requires an interface not available in your driver. But that is a pretty basic mistake, it should not happen often, and there is a good error message when it does happen (and the record will be in an alarm state as well).
You also said:
> I guess in the future we will have more asyn based device support.
I think a more accurate statement would be:
"I guess in the future we will have more asyn drivers that use the standard asyn device support."
You should not need to add device support (in the EPICS sense of the word) just asyn drivers.
Cheers,
Mark
________________________________________
From: Abadie Lana [[email protected]]
Sent: Thursday, February 23, 2012 10:33 AM
To: Abadie Lana; Mark Rivers; [email protected]
Subject: RE: Best pratices for compiling dbd files for asyn base device support
Ok so for the timing card
I can send our dbd files ( I think we are in the second case as I can see a registrar(nisyncDrvRegister)
Extract of the nisync.dbd (contains asyn.dbd)
device(waveform,INST_IO,asynInt16ArrayWfIn,"asynInt16ArrayIn")
device(waveform,INST_IO,asynInt16ArrayWfOut,"asynInt16ArrayOut")
device(waveform,INST_IO,asynInt32ArrayWfIn,"asynInt32ArrayIn")
device(waveform,INST_IO,asynInt32ArrayWfOut,"asynInt32ArrayOut")
device(waveform,INST_IO,asynFloat32ArrayWfIn,"asynFloat32ArrayIn")
device(waveform,INST_IO,asynFloat32ArrayWfOut,"asynFloat32ArrayOut")
device(waveform,INST_IO,asynFloat64ArrayWfIn,"asynFloat64ArrayIn")
device(waveform,INST_IO,asynFloat64ArrayWfOut,"asynFloat64ArrayOut")
device(asyn,INST_IO,asynRecordDevice,"asynRecordDevice")
driver(drvAsyn)
registrar(nisyncDrvRegister)
registrar(asSub)
registrar(asynRegister)
registrar(asynInterposeFlushRegister)
registrar(asynInterposeEosRegister)
variable(asCaDebug,int)
variable(dbRecordsOnceOnly,int)
variable(dbBptNotMonotonic,int)
[abadiel@trunk ~]$
To initialize the timing card in our IOC, we have to add the following lines In configure/release NISYNC=${EPICS_MODULES}/nisync NISYNCGT=${EPICS_MODULES}/nisync-generalTime
In the XXXApp/src/Makefile
# Include dbd files from all support applicationss nisync-sample_DBD += nisync-generalTime.dbd nisync-sample_DBD += nisync.dbd
# Add all the support libraries needed by this IOC nisync-sample_LIBS += nisync-generalTime nisync-sample_LIBS += asyn nisync-sample_LIBS += nisync-epics
and then in the IOC
## load nisync driver
nisyncDrvInit("S0", "PXI-6682", "0")
#asynPXI6682DrvInit("S0","0")
#asynSetTraceMask("S0",0,0xffff);
## general time support
nisyncTimeInit("0", "PXI-6682", "0")
Then for flexRIO, we have
A dbd file nrio.dbd which has this line
registrar("asynNirioDrvRegister")
To use it one has to do
nirio-sample_DBD += asyn.dbd
nirio-sample_DBD += nirio.dbd
# Add all the support libraries needed by this IOC nirio-sample_LIBS += nirio nirio-sample_LIBS += asyn in st.cmd we have
nirioinit("RIO2","PXI-7952R","7952FPGA","V2.12")
I guess in the future we will have more asyn based device support.
Finally in our case an IOC can load many types of cards.
Thanks for your feedback
Lana
-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: 23 February 2012 17:00
To: Abadie Lana; [email protected]
Subject: RE: Best pratices for compiling dbd files for asyn base device support
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
- References:
- Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Goetz Pfeiffer
- Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Eric Norum
- Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Andrew Johnson
- Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Goetz Pfeiffer
- Best pratices for compiling dbd files for asyn base device support Abadie Lana
- RE: Best pratices for compiling dbd files for asyn base device support Mark Rivers
- RE: Best pratices for compiling dbd files for asyn base device support Abadie Lana
- RE: Best pratices for compiling dbd files for asyn base device support Mark Rivers
- RE: Best pratices for compiling dbd files for asyn base device support Abadie Lana
- RE: Best pratices for compiling dbd files for asyn base device support Mark Rivers
- RE: Best pratices for compiling dbd files for asyn base device support Abadie Lana
- Navigate by Date:
- Prev:
RE: Best pratices for compiling dbd files for asyn base device support Abadie Lana
- Next:
RE: QT-based tools: Expressions of interest requested david.hickin
- 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:
RE: Best pratices for compiling dbd files for asyn base device support Abadie Lana
- Next:
Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Andrew Johnson
- 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
|