Thanks a lot, Mark!
Your description sounds very appropriate.
I will apply your patch to our trunk version to have it tested with our
ASYN based drivers after the next nightly build (early next week).
I also added a GitHub issue - mainly for our internal QA system to have
a link with my "reported upstream" statement.
NB: You can auto-close GitHub issues through adding text tags to commit
messages. [1] This will immediately create a link from the issue to the
commit, and close the issue when the change gets merged into the default
branch - very convenient.
Thanks again, and I will keep you posted with the results of testing
your branch.
Cheers,
~Ralph
[1] https://help.github.com/articles/closing-issues-via-commit-messages/
On 02/10/2015 02:01, Mark Rivers wrote:
Hi Ralph,
I have changed all of the devEpics code to fix the problem you pointed out. Now the processRrrr() routines do not set the record value and return -1 under the following conditions:
- For records with SCAN != I/O Intr:
- pasynManager->queueRequest() fails OR
- pasynXXX->read() function returns an error
- For records with SCAN == I/O Intr
- The interrupt callback function is passed pasynUser->auxStatus != asynSuccess
The only exception to the above is for devAsynOctet and devAsynXXXArray records with SCAN != I/O Intr. For these records the value will be modified even if the pasynXXX->read() function returns an error. The reason is that there is no buffering, so the value has already been modified by the time we know there was an error.
I have tested with the testErrorsApp test application in asyn. I used the asynRecord to disconnect the port. I also changed the status that is returned by the pasynXXX->read() function and the pasynUser->auxStatus for I/O Intr scanned records. The behavior seems to be correct.
I have committed these changes to a new status_return branch in the git repository: https://github.com/epics-modules/asyn
If you do a "git pull" and "git checkout status_return" you can test on your system to make sure it works correctly. I can then merge those changes with the master branch.
Mark
-----Original Message-----
From: Ralph Lange [mailto:[email protected]]
Sent: Thursday, October 01, 2015 8:08 AM
To: Mark Rivers
Cc: EPICS Core-Talk
Subject: ASYN Device Support Issue
Hi Mark,
The processRrrr() routines of the ASYN Device support for input records
always set the VAL (or RVAL) field and return success, even if the call
to queueRequest() acquiring the value fails.
In our case, with a non-blocking ASYN driver for a PXIe board, the RVAL
field of the mbbi record showing the board status is always set to 0 (=
"OK"), even when there is no such board present and the device never
connects.
We are pre-setting the database with 4 = "no board", but that gets
overwritten with 0 ="OK" at every processing.
That doesn't seem right, does it?
Shouldn't the process routine leave the value unchanged and return an
error when reading fails?
Thanks a lot,
~Ralph
- Replies:
- RE: ASYN Device Support Issue Mark Rivers
- References:
- ASYN Device Support Issue Ralph Lange
- RE: ASYN Device Support Issue Mark Rivers
- Navigate by Date:
- Prev:
RE: ASYN Device Support Issue Mark Rivers
- Next:
RE: ASYN Device Support Issue Mark Rivers
- Index:
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: ASYN Device Support Issue Mark Rivers
- Next:
RE: ASYN Device Support Issue Mark Rivers
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|