Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Tue, 6 Oct 2015 18:31:38 +0000

Hi Ralph,

Have you had a chance to test it yet?  I'd like to release asyn R4-27 this week if possible.

Thanks,
Mark

-----Original Message-----
From: Ralph Lange [mailto:[email protected]] 
Sent: Friday, October 02, 2015 3:25 AM
To: Mark Rivers
Cc: EPICS Core-Talk
Subject: Re: ASYN Device Support Issue

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System