3.
The IMS offers two levels for user information exchange. The most elementary is the "Command Language," and the more sophisticated approach is called "ScreenLink." Each of these approaches is outlined below.
Command Language: In this mode, the IMS traffics in simple messages composed of ASCII character strings. The only GPIB functionalities used are Read and Write. The IMS exercises the newer IEEE-728 specification for string handling, which uses, among other things,
carriage return followed by a
line feed as the string terminator. The IMS strips carriage returns from strings it receives, but embeds them in strings that it transmits. Hence, omitting a carriage return from a string being sent to the IMS has no effect; omitting a line feed can be fatal!
Note: Much of the IMS software/firmware has been developed on IBM-PCs using the Lattice C compiler. Their nomenclature for carriage return and line feed is exactly opposite to that used in Cedar. IMS code uses the Kernighan & Ritchie/UNIX convention of \r, \n for carriage return and line feed ("newline") respectively, whereas Cedar uses the convention, \n and \l. This notational difference was not explicitly documented in the code examples supplied by IMS, Inc. and was at the seat of early confusion in software development. Using the more explicit CR and LF (see the point about pseudocode below) would be helpful for those of us who are not UNIX groupies!
Unlike some HP instruments, IMS adheres to the convention of asserting EOI with the last byte transmitted. There is, however, one exception to this rule. The transmission of a single status byte during a Serial Poll does not include EOI. More on this point in Section 4.
Multiple line
commands look like:
RESource inputs = force #txt
1 a2 in2 2
1 a1 in1 1
RES end
Using the
query form would return:
RES? inputs
1 a2 in2 2
1 a1 in1 1
A complete listing of the available commands is given in the IMS Command Reference Guide.
The current Cedar 6.0 software which allows the user to interact with the IMS at the Command level is called "IMSCommander" and can be retrieved from:
[DATools]<DATools6.0>Top>IMSCommander.df
Screen Link: The IMS possesses on-board firmware which provides user interaction through so called "screens." Since most commercially available computer systems come with a glass teletype terminal with a character generating ROM, the IMS attempts to make the environment more friendly for such users by formatting information into character arrays or screens. In the Xerox environment with bitmapped, large format displays, this approach is anathema. This is not to detract from IMS; they are in the business to stay in business by selling testers and most commercial establishments use anything but Xerox workstations. From a purely business point of view, IMS has not only done the right thing, they've done it well!
To better understand the IMS tester and its screenlink capability, it was necessary to first construct the right kind of interpreter to translate the screen control code of the IMS into a form that could be displayed in a Cedar viewer. This turned out to be more difficult than expected.
The language used for providing the screenlink is essentially a superset of the the Command language described above, and uses the keyword "Key" in both the imperative sense and the interrogative sense. As the word implies, "Key" refers to the keys of the keyboard. Things remain straightforward as long as one is considering only the standard alphanumeric keys.
Note: A particular key is captured as a character but transmitted to the IMS as its ASCII decimal equivalent. In Cedar this is achieved through the use of Formatted Ropes, e.g.,
IO.PutFR["Key %g\l", IO.card[LOOPHOLE[key]]]
However, it is assumed by the IMS, that control functions, e.g., activating screens and "pop-up" menus, will be communicated through the use of ASCII control or escape sequences. For most commercial computer systems this implies the use of function keys or alternate keypads. The escape sequences associated with function keys vary widely among computer brands. The question arises, how does the IMS know about the terminal type with which it is supposed to communicate?
IMS, Inc. has provided a so-called "Learn" capability. The IMS uses its own internal fixed representation for generic keys. A correspondence between the internal IMS representation and a particular physical keyboard can be taught to the preprocessor in order to establish the rules of ASCII communication. In this way the IMS "learns" the nature of the keyboard and terminal you are using. There is a separate preprocessor syntax, based once again on the base Command Language, which can be used to record the terminal attributes in a file to be downloaded after the IMS powers up. There is also a default
setting which assumes the terminal being used is a VT00.
Note: Explicit escape sequences, i.e., ESC someKey, are transmitted to the IMS as the appropriate ASCII decimal equivalent for someKey, prepended by the code assigned to the ESC key. In Cedar, this is achieved through the use of Formatted Ropes, e.g.,
IO.PutFR["Key ESC %g\l", IO.card[LOOPHOLE[key]]]
In the case of a VT100, ESC is 1; an IBM-pc uses 0.
Note: More information about the Learn Command language is available in Appendix D (not included in the original documentation). This chapter is quite involved and difficult to digest on a single reading. There should be a higher level chapter which gives a better overview of the intent behind the Learn Commands with references to Appendix D for more detailed discussion. Because of this omitted overview, there are things in Appendix D which appear inconsistent, e.g., Table D-5 gives a list of internal key assignments. There are unexplained gaps in the numbers used. Some codes refer to actual keys of the keyboard while other codes refer to IMS functions like initialization of the tester. There is no mapping of key codes to screen functionality. For example, Key 150 is defined as referring to Function Key 1, but nothing is said about what will happen when one in fact presses that key on the keyboard! It can be deduced that it will activate the Configuration Screen only by close inspection of other parts of the general documentation. This whole situation is aggravated when the computer/ terminal being used does not possess function keys, as is the case with a VT100. In the Cedar environment, function keys are replaced with Tioga menu buttons.
Note: During the course of developing the screenlink capability in Cedar, it was discovered that if a separate configuration file was not explicitly downloaded, strange status bytes were generated when the IMS was prompted for screens and the screens did not appear. The reason for this strange behavior was the missing command sequence:
GPIB.WriteDevice[gh.addr, "lea com\lEnd\lKey 129\lSRQ 7\l"];
This sequence is transmitted at the end of the downloading of a configuration file. If the default mode is chosen instead, and no downloading takes place, the IMS never receives this final command sequence and gets confused when prompted for a screen; particularly a Configuration Screen. This point is not currently documented by IMS, Inc. A work-around has been incorporated in Cedar 6.0.
Note: There is an Application Note in the current documentation which purports to describe a simple screenlink program. Although it provides an outline, it has several disadvantages and has since been disowned by IMS, Inc. Unfortunately, the other incarnations I have seen still suffer several disadvantages. Not the least of these is that all the example code assumes from the outset that the screenlink will be running on a monoprocessor, like an IBM-pc. Clearly, Xerox systems, with their intrinsic concurrency, would have all their horsepower usurped by code that is written in the style suggested by IMS, Inc., e.g, a mainline polling loop. Although IMS code is well written (for C code), the choice of C as the language in which to write examples is not a good one. Pointer dereferencing, use of \n, and distinguishing the bottom of a loop from the end of a function block are examples of the kind of thing that can be a headache when translating C into another language. It has been suggested to IMS, Inc. that they write their examples in a carefully worded pseudocode (perhaps taking a hint from Cedar reserved words and style) with references to particular chunks of C code where appropriate.
The current software which allows the user to interact with the IMS at the screen level is called "IMSScreenLinker" and can be retrieved from:
[DATools]<DATools6.0>Top>IMSScreenLinker.df