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