EPICS Home

Experimental Physics and Industrial Control System


 
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  <20192020  2021  2022  2023  2024  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  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: StreamDevice processing issue
From: Dirk Zimoch via Tech-talk <[email protected]>
To: "Davis, Mark" <[email protected]>, EPICS <[email protected]>
Date: Fri, 15 Mar 2019 17:00:23 +0100
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]


Replies:
Re: StreamDevice processing issue Davis, Mark via Tech-talk
References:
StreamDevice processing issue Davis, Mark via Tech-talk

Navigate by Date:
Prev: StreamDevice processing issue Davis, Mark via Tech-talk
Next: Re: StreamDevice processing issue Davis, Mark via Tech-talk
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  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: StreamDevice processing issue Davis, Mark via Tech-talk
Next: Re: StreamDevice processing issue Davis, Mark via Tech-talk
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  <20192020  2021  2022  2023  2024