Hi,
while Mark focused on answering the crash, let me chip in about the
read-back not working.
It depends on your device implementation. In most simple case you may
want the same value that was pushed to writeInt32 to also show up in the
read-back record. This only reflects the fact that software has received
the requested value. Make sure to call setIntegerParam() followed by
callParamCallbacks(), or simply invoke asynPortDriver default
writeInt32() handler:
asynStatus MyDrv::writeInt32(asynUser *pasynUser, epicsInt32 value) {
if (pasynUser->reason == BOARD_ID) {
writeToDev(value);
setIntegerParam(pasynUser->reason, value);
callParamsCallbacks();
return asynSuccess;
}
// rest of your code
}
or simply
asynStatus MyDrv::writeInt32(asynUser *pasynUser, epicsInt32 value) {
if (pasynUser->reason == BOARD_ID) {
writeToDev(value);
}
return asynPortDriver::writeInt32(pasynUser, value);
}
For this simple case you could also merge set-point and read-back
records into one by using asyn:READBACK.
What you probably want to do is to read value from the device. Once you
have the value, again make sure to use setIntegerParam() followed by
callParamCallbacks(). It's the callParamCallbacks() that schedules
processing of I/O Intr records.
-- Klemen
On 5/27/19 5:44 PM, Mark Rivers via Tech-talk wrote:
I forgot to CC tech-talk.
*From:*Mark Rivers
*Sent:* Monday, May 27, 2019 4:43 PM
*To:* 'Pilar' <[email protected]>
*Subject:* RE: I/O Intr scanning
Hi Pilar,
First, you have not provided enough information to let us help you
figure out the problem. What is your driver doing when you write
BoardIDSet? What you are trying to do should work, since there are lots
of other drivers that do the same sort of thing with no problems.
Second, you have set some compiler flags so that you are getting very
little useful information in your traceback. It is not showing you the
line numbers, or demangling the C++ function names.
I have manually demangled the names of the last 3 functions called:
/home/epicsmgr/EPICS/support/asyn/lib/linux-x86_64/libasyn.so(_ZN8paramValD1Ev+0x11)[0x7f145d2d7611]
This is paramVal::~paramVal(), in asynPortDriver.
/home/xxx/bpm/bpm_epics/lib/linux-x86_64/libewbasyn.so(_ZN15EWBAsynGenPVPrmD0Ev+0x9)[0x7f145c09bec9]
This is EWBAsynGenPVPrm::~EWBAsynGenPVPrm(), in your class
/home/xxx/bpm/bpm_epics/lib/linux-x86_64/libewbasyn.so(_ZN15EWBAsynPortDrvr10writeToDevEii+0x4e)[0x7f145c09ad1e]
This is EWBAsynPortDrvr::writeToDev(int, int)
So your writeToDev function is calling the destructor for your
EWBAsynGenPVPrm object, which is in turn calling the destructor for the
paramVal object. This seems unusual. What object are you destroying
when a new integer value is written to your driver?
You need a better traceback, and you will need to send your code if we
are to help.
Mark
*From:*[email protected]
<mailto:[email protected]> <[email protected]
<mailto:[email protected]>> *On Behalf Of *Pilar via Tech-talk
*Sent:* Monday, May 27, 2019 3:19 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* I/O Intr scanning
Dear all,
I'm using a asynPortDriver (4.33) with EPICS base (3.16).
The way I create my asynPortDriver is:
EWBAsynPortDrvr(const char *portName,int max_nprm)
: asynPortDriver(portName,
1,
(asynInt32Mask | asynFloat64Mask | asynOctetMask |
asynDrvUserMask), /* Interface mask */
(asynInt32Mask | asynFloat64Mask | asynOctetMask), /* Interrupt
mask */
0, /* asynFlags. This driver does not block and it is not
multi-device, so flag is 0 */
1, /* Autoconnect */
0, /* Default priority */
0), /* Default stack size*/
and I have one example PV defined as:
record(ao, "$(user):BoardIDSet")
{
field(DTYP ,"asynInt32")
field(OUT ,"@asyn($(PORT),$(ADDR),$(TIMEOUT))board_ID")
field(DESC ,"Board Identification")
field(VAL , "3")
field(LOPR, "0")
field(HOPR, "5")
field(PINI ,"YES")
}
record(ai, "$(user):BoardIDRdbk")
{
field(DTYP ,"asynInt32")
field(INP ,"@asyn($(PORT),$(ADDR),$(TIMEOUT))board_ID")
field(SCAN ,"I/O Intr")
field(DESC ,"Board Identification")
}
If I set BoardIDSet to a certain value (for example: 3) BoardIDRdbk does
not see the change and it doesnt get updated. But if I try to write
again BoardIDSet following error ocurrs:
Error in `/home/sevensols/bpm/bpm_epics/bin/linux-x86_64/AsynBPM7S':
double free or corruption (fasttop): 0x00000000023e1b70 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81489)[0x7f145ae31489]
/home/epicsmgr/EPICS/support/asyn/lib/linux-x86_64/libasyn.so(_ZN8paramValD1Ev+0x11)[0x7f145d2d7611]
/home/xxx/bpm/bpm_epics/lib/linux-x86_64/libewbasyn.so(_ZN15EWBAsynGenPVPrmD0Ev+0x9)[0x7f145c09bec9]
/home/xxx/bpm/bpm_epics/lib/linux-x86_64/libewbasyn.so(_ZN15EWBAsynPortDrvr10writeToDevEii+0x4e)[0x7f145c09ad1e]
/home/epicsmgr/EPICS/support/asyn/lib/linux-x86_64/libasyn.so(+0x37ae2)[0x7f145d2d8ae2]
/home/epicsmgr/EPICS/support/asyn/lib/linux-x86_64/libasyn.so(+0x44be5)[0x7f145d2e5be5]
/home/epicsmgr/EPICS/support/asyn/lib/linux-x86_64/libasyn.so(+0x16658)[0x7f145d2b7658]
/home/epicsmgr/EPICS/support/asyn/lib/linux-x86_64/libasyn.so(+0x45af9)[0x7f145d2e6af9]
/home/epicsmgr/EPICS/base/lib/linux-x86_64/libdbRecStd.so.3.16.1(+0xe998)[0x7f145ce3d998]
/home/epicsmgr/EPICS/base/lib/linux-x86_64/libdbCore.so.3.16.1(dbProcess+0x1d8)[0x7f145cbc4508]
/home/epicsmgr/EPICS/base/lib/linux-x86_64/libdbCore.so.3.16.1(dbPutField+0x3ce)[0x7f145cbc617e]
/home/epicsmgr/EPICS/base/lib/linux-x86_64/libdbCore.so.3.16.1(dbChannel_put+0x9e)[0x7f145cbe07fe]
/home/epicsmgr/EPICS/base/lib/linux-x86_64/libdbCore.so.3.16.1(+0x648a4)[0x7f145cc068a4]
/home/epicsmgr/EPICS/base/lib/linux-x86_64/libdbCore.so.3.16.1(camessage+0x9d)[0x7f145cc0515d]
/home/epicsmgr/EPICS/base/lib/linux-x86_64/libdbCore.so.3.16.1(camsgtask+0x13c)[0x7f145cc0203c]
/home/epicsmgr/EPICS/base/lib/linux-x86_64/libCom.so.3.16.1(+0x40b6c)[0x7f145c706b6c]
Can somebody tell me whay the I/O Scan is not working? And also why this
error ocurrs
Thank you very much in advance!
--
http://sevensols.com <http://sevensols.com>
Pilar Gil Jaldo
Embedded SW Engineer
This e-mail and any materials attached hereto, including, without
limitation, all content hereof and thereof are confidential and
proprietary to Seven Solutions,S.L and/or its affiliates, and are
**confidential**. Without the prior written consent of Seven Solutions,
this content may not (i) be disclosed to any third party, (ii) be
reproduced, modified or otherwise used by anyone other than current
employees of Seven Solutions or its affiliates. If you are not the
intended recipient or if this message has been received in error, please
immediately notify us via e-mail and delete it.
This e-mail and any materials attached hereto, including, without
limitation, all content hereof and thereof are confidential and
proprietary to Seven Solutions,S.L and/or its affiliates, and are
*confidential*. Without the prior written consent of Seven Solutions,
this content may not (i) be disclosed to any third party, (ii) be
reproduced, modified or otherwise used by anyone other than current
employees of Seven Solutions or its affiliates. If you are not the
intended recipient or if this message has been received in error, please
notify us immediately via e-mail and delete it.
- References:
- I/O Intr scanning Pilar via Tech-talk
- FW: I/O Intr scanning Mark Rivers via Tech-talk
- Navigate by Date:
- Prev:
Re: Problem with a calc record Ralph Lange via Tech-talk
- Next:
Re: Scanning 101 Jemian, Pete R. via Tech-talk
- 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:
FW: I/O Intr scanning Mark Rivers via Tech-talk
- Next:
Problem with a calc record CAPOBIANCO Roberto via Tech-talk
- 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
|