HI all,
I am working on a StreamDevice interface for an Edwards STP
turbomolecular pump and am having a problem with processing of one of
the longer replies.
The connection to the pump consists of a TCP connection from the IOC to
a 4-port Moxa serial/Ethernet server and an RS-232 connection between
the Moxa and the pump running at 9600 baud.
So far, everything works fine this way except for the one case where the
Moxa is breaking the response up in to multiple packets.
Below are the protocol definitions for the problem case. Using the data
capture ability of the Moxa (or the asyn trace commands, although that
appears to be limited to showing a max of 80 of the bytes received for
each packet, even though the counts are correct) , I can see that the
device is sending the expected response, and that the ReadEventsWT
protocol (linked to a record that scans periodically) is processing the
2nd and 3rd "out" commands at the appropriate time, which tells me it
must be getting all the bytes expected for each "in" command despite
that fact that they are split across 2 or 3 packets. This is further
supported by that fact that, before I got the character counts correct,
I was getting a CALC error for the record linked to the ReadEventsWT
protocol.
The problem appears to be that the ability to match a sequence of bytes
for the "in" command when the bytes span multiple packets does not work
for protocols that do not start with an "out" command (i.e. those linked
to "I/O Intr" records).
Is this a known problem? Has anyone run across this before?
I understand that this would not be a trivial issue to fix. To make
this work, StreamDevice would have to determine the maximum length of
bytes expected by all the "in" commands in protocols that had no "out"
commands, and each time new bytes were received, retesting for a match
for each of those protocols would have to include not just the most
recently received bytes but enough of the ones that came before it to
guarantee that you did not miss a match.
Looking at the examples portion of the StreamDevice doco pages, I expect
there is a good chance that if I treated every packet like a separate
"line" of input, with one "in" command for each packet, that would allow
it to work. But even if it did, it would require that the Moxa always
broke up the responses in to the same size packets, and that the
protocol knew what that size was. Not exactly a recipe for reliable
operation.
There are some other possibilities I will be looking in to that might
force the Moxa to send the entire response as one packet, but this seems
like an issue that could apply to other devices, especially when a Moxa
or similar device is part of the connection.
NOTE: I am currently using StreamDevice version 2.5. Even before this
issue came up I tried 2.6 but it didn't work (I don't remember exactly
what the problem was, and I didn't have time then to look in to it) so I
went back to 2.5.
##-----[ReadEventsWithTime]----------------------------------------------------
# Record for this protocol must process periodically ReadEventsWT { out
"\x02" "001?}" "\x03%<xor8ff>"; in "\x06\x02" "001 }%253c" "\x17%*1c";
out "\x06"; in "\x02" "002%*151c" "\x03%*1c"; out "\x06"; } # records
for these protocols must use "I/O Intr" SCAN # These assume err time
flag format = "01" curNumErrs { in "\x02" "001 }%2x"; } # current # of
errors maxNumErrs { in "\x02" "001 }%*2c%2x"; } # max # of errors
err1Type { in "\x02" "001 }%*4c%2x"; } # Error 1 # err1Date { in "\x02"
"001 }%*8c%6c"; } # Error 1 date (YYMMDD) err1Time { in "\x02" "001
}%*14c%4c"; } # Error 1 time (HHMM) err2Type { in "\x02" "001
}%*24c%2x"; } # Error 2 # err2Date { in "\x02" "001 }%*28c%6c"; } #
Error 2 date (YYMMDD) err2Time { in "\x02" "001 }%*34c%4c"; } # Error 2
time (HHMM) err3Type { in "\x02" "001 }%*44c%2x"; } # Error 3 # err3Date
{ in "\x02" "001 }%*48c%6c"; } # Error 3 date (YYMMDD) err3Time { in
"\x02" "001 }%*54c%4c"; } # Error 3 time (HHMM) err4Type { in "\x02"
"001 }%*64c%2x"; } # Error 4 # err4Date { in "\x02" "001 }%*68c%6c"; } #
Error 4 date (YYMMDD) err4Time { in "\x02" "001 }%*74c%4c"; } # Error 4
time (HHMM) err5Type { in "\x02" "001 }%*84c%2x"; } # Error 5 # err5Date
{ in "\x02" "001 }%*88c%6c"; } # Error 5 date (YYMMDD) err5Time { in
"\x02" "001 }%*94c%4c"; } # Error 5 time (HHMM) err6Type { in "\x02"
"001 }%*104c%2x"; } # Error 6 # err6Date { in "\x02" "001 }%*108c%6c"; }
# Error 6 date (YYMMDD) err6Time { in "\x02" "001 }%*114c%4c"; } # Error
6 time (HHMM)
______________________________________
Mark Davis
NSCL/FRIB Control Systems Software Engineer
[email protected]