Argonne National Laboratory

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  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 
<== Date ==> <== Thread ==>

Subject: StreamDevice processing issue
From: "Davis, Mark via Tech-talk" <tech-talk@aps.anl.gov>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 15 Mar 2019 15:38:58 +0000
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
davism50@msu.edu


Replies:
Re: StreamDevice processing issue Dirk Zimoch via Tech-talk
Re: StreamDevice processing issue Lucock, Richard M via Tech-talk

Navigate by Date:
Prev: PVAccess RPC server on top of Matlab? Ralph Lange via Tech-talk
Next: Re: StreamDevice processing issue Dirk Zimoch 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 
Navigate by Thread:
Prev: PVAccess RPC server on top of Matlab? Ralph Lange via Tech-talk
Next: Re: StreamDevice processing issue Dirk Zimoch 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 
ANJ, 18 Mar 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·