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
- Replies:
- Re: hex stream processing with StreamDevice? Dirk Zimoch
- RE: hex stream processing with StreamDevice? Barker, Alan M.
- References:
- hex stream processing with StreamDevice? Barker, Alan M.
- Navigate by Date:
- Prev:
CA gateway dies without error message Dirk Zimoch
- Next:
agenda for the October meeting is updated (you may be scheduled to give a ttalk ; ) ) Dalesio, Leo
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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:
hex stream processing with StreamDevice? Barker, Alan M.
- Next:
Re: hex stream processing with StreamDevice? Dirk Zimoch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|