Experimental Physics and
Industrial Control System

LockTimeout = 20000;  # max wait for exclusive access to the device
WriteTimeout =  500;  # max wait to be able to write to the device
ReplyTimeout = 1000;  # max wait until the start of a reply
ReadTimeout =  1000;  # max idle time after start of reply
PollPeriod =    200;  # How often to poll for new input for "I/O Intr" mode records

ExtraInput = Ignore;
MaxInput = 0;

Hi Mark,

Have you tried to increase ReadTimeout? It should be longer that the gap between two packages.

As your device neither has separators (because it is binary, not ASCII) nor fixed input length, timeout is about the only thing to define "end of input". So you need to fine-tune ReadTimeout somewhere between the delay between packages and the delay between messages.

I do not have such a device, but I can try to write a simulation. But that will take a while.

Best regards,
Dirk

On 15.03.19 16:38, Davis, Mark via Tech-talk wrote:

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]