Gentlemen,
-
I have read and re-read the VSI-S comments that I have received over the past couple of weeks and have put together VSI-S draft 3 which attempts to make the best of a bit of a difficult situation.  It is a major overhaul and is, hopefully, a major step in the direction that everyone can be reasonably happy with.  Below is a summary of some of the issues and my response as embodied in attached VSI-S draft 3:
-
Unsolicited Responses from DTS
Issue:  Should unsolicited messages from the DTS be allowed?
Discussion:  There seems to be a general feeling that unsolicited responses of any type should not be allowed.  This implies that the DTS speaks only when spoken to, in a true half-duplex fashion.  This certainly does simplify communications, but does mean that it is the controller's responsible to frequently poll the DTS for status and errors.
Recommendation:  The DTS will respond only to a command or query, and will *never* issue unsolicited messages.  Note that this removes the half/full duplex option;  all communications are half-duplex.
-
Response times and timeouts
Issue:  What should be the timeout period for the DTS response to a controller command or query?
Discussion:  In draft 2, a timeout period of 0.5 seconds is specified.  Ed Himwich has suggested that a very short time-out period (a few character periods) is better, and I have heard no real opposition to this.  For local communications, a short time-out period would be suitable, while communications over a long-haul network might require a much longer time-out (order of seconds in some circumstances).
Recommendation:  The DTS shall respond to any command/query within 50 msecs or 100 character periods (for RS-232 operation), whichever is longer.  The timeout set by the controller is a function of the communications environment and is left to the discretion of the controller.  In the event of a non-reply from the DTS within the prescribed time, the controller may issue a new command/query (perhaps a retry).  However, after a normal reply is received from a DTS, the controller may immediately issue the next command/query with no further delay.  No specification or limit on retries.
-
DOTset/ROTset query
Issue:  As specified in draft 2, the DOTset/ROTset queries can wait up to 1 second for a response, which will now violate the new response-time rules.
Discussion: I agree with Ed Himwich's recommendation that the DOTset/ROTset queries return immediately with high time resolution.   Millisecond level is sufficient, with higher resolution allowed.  The time format remains the same, but with the allowance for fractional seconds.
Recommendation: As above.  Millisecond resolution is mandated, higher resolution allowed.
-
Sequence numbers
Discussion:  Sequence numbers do not seem to be very much needed if  there is a direct reply to every c/q.  The suggested response syntax is self-identifying and should create little confusion wrt cause and effect.
Recommendation:  Drop sequence numbers.
-
Packet structure
Discussion:  My reading of the consensus, as best as I can judge, is that TCP/IP communications is well protected against errors and does not need an error-detection structure.  RS-232, on the other hand, can occasionally be subject to errors and should be protected to some degree, although not everyone agrees on this point.   I like Brent's suggestion of  thinking of communications layers and allowing TCP/IP and RS-232 to diverge at layer 3 level. 
Recommendation: I suggest the following:
TCP/IP packet: <command/response>
RS-232 packet - two options:
User option Type 1: <SOH><command/response><C><CR>
User option Type 2: <command/response><CR>
Although this is a bit more complex, every user can hopefully be fully satisfied by choosing their preferred option.
-
Command/Query Case Folding
Issue:  Some respondents have explicitly requested the c/q case be arbitrary.
Discussion:  I haven't heard any opposition to this request, so have adopted it.
Recommendation: All keywords and command fields of type 'char' are case insensitive, as well as letters embedded in hex fields.  Literal ASCII (quote-enclosed) is case sensitive.  Response 'char' fields are also insensitive, but it is suggested that they be returned in lower-case.
-
DTS-specific content in query responses
Issue: Should DTS-specific fields be allowed in responses to standard VSI queries?
Discussion:  I feel that allow these DTS-specific fields as trailing fields in queries is highly useful since it allows clarification of the particular DTS's situation in cases where meanings may be somewhat different for different DTS's.  Adding a separate set of DTS-specific queries seems to me to just add complications and command proliferation.
Recommendation: Leave DTS-specific query-response fields as specified in draft 2.
-
'Comment' Informational Commands
Issue:  Allow comments as information commands?
Discussion: It has been noted that some DTS's may keep internal logs, for which comments may be useful.  In addition, comments may be routed out through QDATA, which could be used for special purposes in a DPS.  The bandwidth occupied by comments is not likely to be great; presumably a controller could simply not issue comments if the DTS doesn't do anything with them.
Recommendation:  Allow comments as specified in draft 2
-
Simultaneous Ethernet/RS-232 control
Issue:  Should both the ethernet and RS-232 control ports be allowed to be active at the same time.
Discussion: Both ports may be active simultaneously on some systems, but using both simultaneously presents potential peril in dealing with command/response timing issues.
Recommendation: Leave to user's discretion, but discourage and warn of possible consequences.
-
Summary
The attached VSI-S draft 3 embodies these recommendations, as well some other significant improvements (at least I hope), particularly in P/QDATA management.  I invite you to study and respond to any and all issues.  Again, I emphasize that  we all need to de-emphasize our own special preferences as much as possible in order to achieve a workable and practical result with which we can all live. Please keep this in mind.  I look forward to your comments.
-
Questions
A coupld of specific questions to you:
1.  Is the prescribed response window appropriate?
2.  Is a restriction of 64 characters/message too restrictive (maybe 128 better?)?
-
Regards, Alan