StreamDevice @mismatch handling following TCP reconnection

[David Jakeman - STFC UKRI via Tech-talk <tech-talk at aps.anl.gov>]

Hello All,

 

Although I am new to this community, I have attempted to thoroughly investigate the problem before seeking assistance. My testing has included:

• Analysis of record status fields (PACT and related fields)
• Wireshark capture and comparison of successful and failed reconnect sequences
• Testing with and without @mismatch
• Protocol modifications to alter mismatch-handling behaviour
• Comparison of behaviour across multiple ports and devices

Based on these tests, I have been able to narrow the issue down considerably, but I am unsure whether my interpretation of the StreamDevice behaviour is correct.

I have a device which communicates with EPICS over TCP. A record sends a command to the device and then expects a response via the following protocol:

 

get_V {     out "V\$1?";

                 in "V\$1=%f";

                  @mismatch {

                                    out "V\$1?";

    in "V\$1=%f";

    }

}

 

If the Ethernet connection is lost and then re-established, I observe an erroneous "read 0". This causes the protocol to enter the @mismatch handler. At this point, the subsequent write from within the @mismatch block appears to fail and I receive a writeRequest error.

My understanding is that the writeRequest error occurs because StreamDevice is attempting to write using a connection that no longer exists, although I am not certain that this interpretation is correct.

Ideally, I would like to specify in the protocol that both of the following are valid responses:

 

V1=<floating point value>

<blank>

 

where a blank response would simply return 0 (or otherwise be ignored) and allow processing to continue normally.

I came across the following discussion, which seemed potentially relevant:

"EPICS Re: Stream Device errors and record initialization"

Based on that discussion, I modified the protocol to:

get_V { out "V\$1?";

                in "%*{V\$1=|}%?f";

@mismatch {

out "V\$1?";

in "V\$1=%f";

}

}

 

This successfully handles the erroneous read following connection loss and recovery. However, it introduces a new concern. If the device were to return an invalid response such as:

 

V1=ABC

 

the protocol appears to accept this as valid and simply return 0, whereas I would ideally like this to be treated as a genuine data error.

My goal is therefore to:

1. Accept valid responses of the form V1(or other variable Vn) =<float>.
2. Accept a blank response and continue processing without entering @mismatch.
3. Reject malformed responses such as V1=ABC and allow them to be handled as errors.

Is there a recommended way to express this behaviour within a StreamDevice protocol?

 

Regards,

David