...

For periodic records StreamDevice does a read with a timeout you define, so it won’t return until multiple packets are received as long as they come within the timeout.

 

Ø  However, this does not appear to be true for protocols that are linked to records using "I/O Intr".  For such protocols, StreamDevice appears to require a 1-to-1 relationship between the packets and the patterns in the "in" commands.  If you know the # and size of each packet, this can be used to define a working protocol (see example below).  But if those values change for whatever reason, then the protocols that depend on them will stop working.

 

I believe that is because StreamDevice does reads for I/O Intr scanned records with a timeout of 0.  So it will return immediately if there is no data available, or will return a single packet if one does arrive.  It will never wait for a second packet.

• For each protocol, keep track of the following:
• Where in the "in" pattern(s) testing for a match needs to resume when we get more input (next-to-match pointer)
  
• The time the previously processed input was received
• Each time we receive new input, perform the following for each I/O Intr protocol:
  
• If part of the pattern(s) has been matched and it has been > ReadTimeout ms since the last input:
• Reset the next-to-match pointer
  
• If no partial match yet, or if it has been < ReadTimeout ms since the last input was received:
• Check to see if the new input advances the match
• If no partial match yet, then match must start at the beginning of the new input
• Failing to match before the end of the input means it does NOT advance the match
• If the match was not advanced, reset the next-to-match pointer
  
• If all the patterns have been matched:
• Complete processing for the protocol
  
• Reset the next-to-match pointer
• If a complete match occurred before we reached the end of the most recently read bytes:
• Process the rest of the input for this protocol (in case the remaining bytes contain even the beginning of another match)
  

• It reduces overhead by limiting the processing of protocols to the times when you expect a match
• It increases the usefulness of the I/O Intr mode by allowing I/O Intr protocols to be used in cases where they can't at present because they could match input that they were not meant to.  This can occur for devices that assume the client knows the context for a response because it had to have sent the request that triggered the response.
• I suppose this approach could even be used to define a "tree" structure of I/O Intr protocols, avoiding the need to include in each protocol all the "nodes" that make up a long prefix that provides the context for each value (branch).  For devices that use a tree structure to specify the context of each value (devices that use SCPI come to mind), this could be used to further reduce the overhead by limiting the processing for each of the "branch" protocols to just the portion of the response that contains the desired value (although I admit many of the SCPI implementations I have seen try to use unique branch names so the entire "path" name is not required to avoid ambiguity).
  
  

Mark

From: [email protected] <[email protected]> On Behalf Of Davis, Mark via Tech-talk
Sent: Monday, March 18, 2019 10:44 AM
To: [email protected]
Subject: Re: StreamDevice processing issue

 

Hi all,

A (relatively) more concise and complete summary of my current issue with StreamDevice:


EPICS 3.14.12.2 IOC using StreamDevice 2.5 and asyn 4-32.

Creates connection to an NPort 6450 4-port serial/Ethernet server using this call:

     drvAsynIPPortConfigure("SCR_BTS35_-TMP_D1612", "192.168.54.218:4006")

(the port # was changed from the default so my development IOC rather than the live IOC can connect)

A 9600 baud RS-232 connection from the Moxa to the Edwards STP-iX3006 Turbomolecular pump.


The basics of the pump serial protocol:  (### = serial transmission block # starting at 001)
   IOC:  <STX>###?<cmd-char><ETX><8-bit-checksum>
  Pump:  <ACK>
  if < 255 bytes of data: 
      Pump:  <STX>###<space><cmd-char><data><ETX><8-bit-checksum>
  else:
      Pump:  <STX>###<space><cmd-char><data><ETB><8-bit-checksum>
  IOC:  <ACK>
  While > 255 data bytes left:
       Pump: <STX>###<another-255-bytes-data><ETB><8-bit-checksum>
       IOC:  <ACK>
  When <= 255 bytes left:
       Pump: <STX>###<remaining-data><ETX><8-bit-checksum>
       IOC:  <ACK>

When the total bytes in a transmission block > 112, the Moxa splits it in to multiple packets.

NOTE:  There is no evidence of any delay between the characters within a serial transmission block from the pump, yet even when I change settings in the Moxa that should result in larger packets (the max packet size is set to 1024, the time to wait for more bytes before sending a packet is set to 1000 ms, the delimiter character is set to <ETX>, ...), it always breaks up any data stream > 112 bytes in to separate packets.  If it were not for the fact that it (supposedly) supports a packet size up to 1024 bytes, I would assume that (as odd a # as that is) it was the max # of data bytes it could send in one packet.


The StreamDevice issue related to this:

For a protocol linked to a periodically processed record, StreamDevice will correctly match the pattern of the "in" commands to the contents of the transmission blocks from the pump, even when individual blocks have been split up in to multiple TCP packets. 

However, this does not appear to be true for protocols that are linked to records using "I/O Intr".  For such protocols, StreamDevice appears to require a 1-to-1 relationship between the packets and the patterns in the "in" commands.  If you know the # and size of each packet, this can be used to define a working protocol (see example below).  But if those values change for whatever reason, then the protocols that depend on them will stop working.

Example from my protocol file:

## times are in milliseconds

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;

##-----[ReadEventsWithTime]----------------------------------------------------

#===== Record for this protocol must process periodically =====

##--- StreamDevice properly matches the "in" patterns to the separate

##--- transmission blocks even when the contents of each block has

##--- been split across multiple TCP packets.

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

#--- The data for these are in the 1st packet of the 1st transmission block 

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)

...

err6Type   { in "\x02" "001 }%*104c%2x"; }  # Error 6 #

##--- The following fail to match the remaining values in the 1st transmission block

##--- that are in the 2nd TCP packet

#err6Date   { in "\x02" "001 }%*108c%6c";  }  # Error 6 date (YYMMDD)

#err6Time   { in "\x02" "001 }%*114c%4c";  }  # Error 6 time (HHMM)

##--- The following work to get the desired values from the 1st transmission block

##--- that are in the 2nd TCP packet

err6Date   { in "\x02" "001 }%*106c";  in "%*2c%6c"; }  # Error 6 date (YYMMDD)

err6Time   { in "\x02" "001 }%*106c";  in "%*8c%4c"; }  # Error 6 time (HHMM)

Sample of the related records:

##=============================================================================

record(stringin, "_$(SYS)_$(SUB):$(DEV)_$(INST):ReadEventsWT") {

  field(DESC, "List of events/errors with times")

  field(SCAN, "5 second")

  field(DTYP, "stream")

  field(INP,  "@Edwards_STP_TMP.proto ReadEventsWT $(PORT)")

}

##--------------------------------------------------------------

record(longin, "$(SYS)_$(SUB):$(DEV)_$(INST):HWER_RD_CNT") {

  field(DESC, "Number of HW err events")

  field(EGU,  "NumErrs")

  field(SCAN, "I/O Intr")

  field(DTYP, "stream")

  field(INP,  "@Edwards_STP_TMP.proto curNumErrs $(PORT)")

}

##--------------------------------------------------------------

record(longin, "$(SYS)_$(SUB):$(DEV)_$(INST):HWER_RD_TYP1") {

  field(DESC, "hdw error 1 event type")

  field(SCAN, "I/O Intr")

  field(DTYP, "stream")

  field(INP,  "@Edwards_STP_TMP.proto err1Type $(PORT)")

}

record(stringin, "$(SYS)_$(SUB):$(DEV)_$(INST):HWER_RD_DT1") {

  field(DESC, "hdw error 1 event date")

  field(SCAN, "I/O Intr")

  field(DTYP, "stream")

  field(INP,  "@Edwards_STP_TMP.proto err1Date $(PORT)")

}

record(stringin, "$(SYS)_$(SUB):$(DEV)_$(INST):HWER_RD_TM1") {

  field(DESC, "hdw error 1 event time")

  field(SCAN, "I/O Intr")

  field(DTYP, "stream")

  field(INP,  "@Edwards_STP_TMP.proto err1Time $(PORT)")

}

...

##--------------------------------------------------------------

record(longin, "$(SYS)_$(SUB):$(DEV)_$(INST):HWER_RD_TYP6") {

  field(DESC, "hdw error 6 event type")

  field(SCAN, "I/O Intr")

  field(DTYP, "stream")

  field(INP,  "@Edwards_STP_TMP.proto err6Type $(PORT)")

}

record(stringin, "$(SYS)_$(SUB):$(DEV)_$(INST):HWER_RD_DT6") {

  field(DESC, "hdw error 6 event date")

  field(SCAN, "I/O Intr")

  field(DTYP, "stream")

  field(INP,  "@Edwards_STP_TMP.proto err6Date $(PORT)")

}

record(stringin, "$(SYS)_$(SUB):$(DEV)_$(INST):HWER_RD_TM6") {

  field(DESC, "hdw error 6 event time")

  field(SCAN, "I/O Intr")

  field(DTYP, "stream")

  field(INP,  "@Edwards_STP_TMP.proto err6Time $(PORT)")

}

Mark