Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: CA_PROTO_READ_NOTIFY Response
From: Mark Davis <davism50@msu.edu>
To: tech-talk@aps.anl.gov
Date: Wed, 02 May 2012 08:17:30 -0400
We are planning on changing from using ModBus to CA for the link between EPICS and our in-house low-powered embedded controllers (ones using Rabbit Core Modules from Digi), so I have recently finished writing and debugging a CA server that could run on this low-end hardware.  In the process I found several errors and a number of places with very confusing and/or contradictory wording that required examination of other working implementations to sort out.

For the READ_NOTIFY response, where it says that the SID should be returned (parameter 5), it appears that this should really be the status code (e.g. ECA_NORMAL).

This is not only supported by examination of the values sent by other implementations, but by this statement in section 13 of the spec on Return Codes:

"Return codes are communicated in the protocol by the CA_PROTO_READ_NOTIFY, CA_PROTO_WRITE_NOTIFY, monitor subscription responses, and the CA_PROTO_ERROR responses."
 
No doubt you could dig in to the EPICS source code to find the definitive answer to this and similar issues.

If it is of use to anyone else, my implementation and notes can be found here:

    https://groups.nscl.msu.edu/controls/

Just download the Rabbit_ST_xxx.zip file and look at the epics_cad.c file in the daemons sub-directory for the code, and the CA_and_ModBus_on_Rabbit_SBCs.doc file in the Documentation sub-directory for my analysis and comments on the CA protocol spec (note that this document is itself a bit out of date and contains some of its own errors, and will be updated shortly).



On 5/2/2012 7:12 AM, graham.cox@stfc.ac.uk wrote:

All,

 

According to the Channel Access protocol specification from the Cosylab website, parameter 1 of the header of a CA_PROTO_READ_NOTIFY response contains the channel SID (the same as the request header received).

 

Is this correct?  Monitoring network traffic from a 3.14.12 win32-x86 soft IOC, this value always appears to a fixed value of 1, no matter what the serverID, or clientID of the channel.  Returning anything other than 1 also appears to break correct functioning of a caget.

 

Thanks,

 

Graham

 

Header

Field

Value

Description

Command

15

Command identifier for CA_PROTO_READ_NOTIFY.

Payload size

Size of payload

Size of DBR formatted data in payload.

Data type

DBR type

Payload format.

Data count

>= 0

Payload element count.

SID

Same as request

SID of the channel.

IOID

Same as request

IOID of this operation.

 


--
Scanned by iCritical.




Replies:
RE: CA_PROTO_READ_NOTIFY Response graham.cox
References:
CA_PROTO_READ_NOTIFY Response graham.cox

Navigate by Date:
Prev: CA_PROTO_READ_NOTIFY Response graham.cox
Next: RE: asynPortDriver callbacks to I/O Intr, how to propagate an error? Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
Navigate by Thread:
Prev: CA_PROTO_READ_NOTIFY Response graham.cox
Next: RE: CA_PROTO_READ_NOTIFY Response graham.cox
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·