Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Fri, 20 Aug 2010 08:11:51 -0500

Hi Alan,

There are many examples of how to write an asyn port driver to handle devices like yours.

The things they have in common are:

- They all use standard asyn device support, so you don't need to write any device support

- They communicate over the asynOctet interface to an underlying asyn port driver, e.g. drvAsynIPPort or drvAsynSerialPort

- They all run either in threads that they create, or in the thread created by asynManager for asynchronous port drivers, so they are allowed to do blocking I/O, which in asyn terminology are called SyncIO calls.  

Here is an example of such a call from the Modbus driver:

    status = pasynOctetSyncIO->writeRead(pPlc->pasynUserOctet,
                                         pPlc->modbusRequest, requestSize,
                                         pPlc->modbusReply, replySize,
                                         MODBUS_READ_TIMEOUT,
                                         &nwrite, &nread, &eomReason);

That call does an atomic write/read operation.  The C code is building the request string from EPICS output records, and is parsing the reply and making the values available to EPICS input records.

The first example is the Modbus driver.  It is written in C and uses the native asynManager and asynOctet interfaces.  It can use either the underlying asyn serial or TCP/IP driver.

http://cars9.uchicago.edu/software/epics/modbus.html

The next examples are the drivers for the marCCD, Pilatus, and mar345 detectors in the areaDetector package.  They use the underlying asyn TCP/IP driver to communicate with the detector servers provided by the vendors.  These drivers are written in C++, and inherit from asynPortDriver (through two intermediate base classes).  They hide most of the details of asynManager.

http://cars9.uchicago.edu/software/epics/areaDetector.html

Cheers,

Mark

________________________________

From: Barker, Alan M. [mailto:[email protected]]
Sent: Thu 8/19/2010 10:00 PM
To: Mark Rivers; [email protected]
Cc: [email protected]
Subject: RE: hex stream processing with StreamDevice?

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