Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Fri, 20 Aug 2010 12:14:22 +0200

Alan,
Maybe you should try to write an interpose layer for asyn that handles
all the "outer" protocol issues and leaves only the user data to stream
or other device support. See the asyn documentation and some example
interpose layers in asyn.
Dirk
Barker, Alan M. wrote:

Dirk and Mark, Thank you for your responses. I don't see how I can use streamDevice, unless I do the "thinking" somewhere else and use it for the low-level socket read and writes. I must use data earlier in the "raw" stream to determine how to handle data later in the same stream. I also have to use past history to determine how to handle processing of the stream.
Here is some more explanation of the protocol, since my example was a bit over-simplified:
1. The <ctrl> byte has a toggle bit that flips on each new message request (and other bits that change over the course of a session).

2. Some messages are sent in multiple packets, and <seq-nbr> decrements down to zero so you know what the last part of a multi-part message is.

3. <data> is not "data" in the sense of a value I am after, but another series of "raw" (hex) values that need to be parsed. For example, the the response to a read service request contains its own nested "packet", with its own count, variable length <data> field, and cksum (different than the outer layer CRC).
I have C code that acts as a TCP client to send() and recv() bytes and parse them with lots of if statements. It would be nice to be able to just integrate that with EPICS somehow.
In the context of the asynDriver documentation, I think my needs are classified as asynchronous, blocks-while-communicating, message based interface with octet arrays, single device support driver, no need to handle interrupts, TCP/IP socket client.
Are there any examples using asynOctet? Any using devGpib or asyn port driver?
Many thanks,
Alan Barker
ORNL

________________________________________
From: Mark Rivers [[email protected]]
Sent: Thursday, August 19, 2010 10:31 AM
To: Barker, Alan M.; [email protected]
Subject: RE: hex stream processing with StreamDevice?
Alan,
You may be able to do everything by just writing a streamDevice protocol
file.  streamDevice can calculate a number of CRCs, it can build and
parse strings, etc.
For example, here is a simple protocol file for an Alcatel pressure
gauge:
InTerminator = CR LF;
ENQ = \005;
ACK = \006;
readPressure {
   out "PR1\r\n";
   in "\${ACK}";
   out "\${ENQ}";
   in  "%*d, %f";
}
To read the pressure the IOC sends "PR1\r\n", and then receives an ACK.
It then sends an ENQ and receives a string response.  It ignores the
first integer number in that response (I forget what what is), skips the
", " characters, and parses the floating point pressure.  That pressure
value could have been a hex number, in which case one would just use a
different C-style format string to parse it.
I am not sure if streamDevice can handle everything in your protocol or
not, but I would first see if it can.
If streamDevice cannot be used, there are several approaches.  You could
use the the devGpib support in asyn, which lets you write your own
parsing code in C.  You could also write an asyn port driver that would
communicate with overlying asyn device support and with the underlying
asyn TCP/IP port driver.
Mark

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Barker, Alan M.
Sent: Wednesday, August 18, 2010 8:01 PM
To: [email protected]
Subject: hex stream processing with StreamDevice?
Hi Tech-talk, I am trying to build a softIOC to support the ANSI C12.22
communications protocol. C12.22 supports TCP/IP Server/Client messaging
where messages are hex streams of the format

<packet> ::= <stp><identity><ctrl><seq-nbr><length><data><crc>
<ack>    ::= 0x06
<nak>    ::= 0x15

where <stp>,<identity>,<ctrl>,<seq-nbr> are always bytes, <length> and
<crc> are always 2 bytes, and how many bytes of <data> is defined by
<length>.

Messages are typically sent in Request/Response pairs, i.e. the client
will ask the server for something, and the server will respond.
The first byte in a request's <data> indicates the message "type", such
as
read or write data to a device. The first byte in a response's <data> is
0x00 for OK, or various other error codes.

Here is an example identification request (0x20) and response to the
request (values shown are hex). You learn from the server its standard
is
0x00, version is 0x02, and revision is 0x00.

Client: EE0000000001201310
Server: 06
Server: EE00000000050000020000C6B5
Client: 06

I am new to EPICS, but have seen that StreamDevice with Asyn can send
and
receive hex values. Most of the examples I have seen are for simple
ASCII
commands like requesting "VOLTAGE?" and receiving "VOLTAGE=120".

In the context of EPICS, where do I parse the incoming hex stream? Where
do I assemble the outgoing hex string? Where do I do my processing (like
calculating the CRC)? In a
genSub? Calc record? State Notion Language? Link to a c file?

Are there any examples out there of sending and processing hex streams?

Thanks,

Alan Barker, ORNL
RHEL 5.5, EPICS R3.14.11, asynDriver R4-14, StreamDevice-2

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System