NOTICE TO CEM USERS

As time goes on, RTS/CEM testing to provide error-free backwards-compatibility becomes increasingly difficult. Therefore, TYX Corporation very strongly recommends that CEM Users recompile and relink their CEM Modules after installing a new version of the RTS.

Overview

1.1 Enhancements

1.1.1 RTS-to-CEM Information Messages:

1.1.1.1 Controller Address Information Message.

1.1.2 CEM Driver access to CEM Kernel Current State Information:

1.1.2.1 Current Module Name.

1.1.2.2 Current Line Number.

1.1.2.3 Current Statement Number.

1.1.2.4 Current Verb.

1.1.3 CEM Driver capability to determine Datum "freshness".

1.1.4 CEM User Stub Functions.

1.2 Problem Reports.- None.

1.3 CEM Help

1.4 CEM User Stub Function

1.4.1 Overview

1.4.2 Enabling

1.4.3 Processing

1.4.4 Formatting

1.4.4.1 Formatting - Action Lines

1.4.4.2 Formatting - Modifier Data Lines

1.4.5 Printing

Detailed Description

2.1 Enhancements

2.1.1 RTS-to-CEM Information Messages.

2.1.1.1 Controller Address Information Message.

With the previous release, RTS and CEM were enhanced so that the RTS would provide the CEM Kernel with Device (but not Controller) Bus Addresses (MTA, MLA and MSA) prior to the first INTERFACE CLEAR / RESET / DEVICE CLEAR sequence.

With this release, the RTS provides the CEM Kernel with Controller Bus Addresses (MTA and MLA) (for the first "Channel" Bus specified in the Bus Configuration File) prior to the first INTERFACE CLEAR / RESET / DEVICE CLEAR sequence. The format of the RTS-to-CEM Controller Bus Addresses Information Message is:

MI MTA:1stCemBus=ControllerMTA MLA:1stCemBus=ControllerMLA

For example:

Note Testing of this feature revealed that there are flaws in the design and implementation of the CEM Model.

The original (and still current) CEM Model design supported only a single "Channel" Bus. Today, however, it is not abnormal for a Test Station to have more than one Instrument Bus (e.g., two IEEE-488 Busses, 2 VXI Busses, or 1 IEEE-488 Bus and one VXI Bus) with all Instruments supported by CEM Instrument Drivers.

Sometime in the past, the CEM Model implementation was modified to allow the specification of multiple "Channel" Busses in the Bus Configuration File. Although these modifications provided limited support for multiple Instrument Busses, in some situations, they simply did not (and still do not) correctly support multiple Instrument Busses.

It is anticipated that multiple Instrument Busses will be correctly supported in the very near future (hopefully in the next RTS release).

2.1.2 CEM Driver access to CEM Kernel Current State Information.

With the previous release, the RTS and CEM were enhanced so that the RTS would provide the CEM Kernel with ATLAS Statement Information. However, that information was not available to CEM Drivers.

With this release, CEM Drivers have access to the following ATLAS Statement Information:

Refer to Section 3 in this document for a full description of these CEM Macros.

2.1.3 CEM Driver capability to determine Datum "freshness".

Prior to this release, CEM Drivers had no way to determine Datum "freshness". This limitation caused CEM Drivers a problem when an ATLAS SETUP Statement specifying a Descriptor Modifier was directed to an active Instrument. For example, if an ATLAS APPLY Statement specifies POS-SLOPE and a subsequent ATLAS SETUP Statement specifies NEG-SLOPE, the CEM Driver Setup Function (called as a result of the ATLAS SETUP Statement) sees a Datum for each Modifier with no way to determine which one is "fresh" (i.e., which one was specified with the ATLAS SETUP Statement).

With this release, CEM Drivers can determine Datum "freshness" by calling the CEM Macros IsOkDatumFresh() and IsDatumFresh(). Refer to Section 3 in this document for a full description of these CEM Macros.

2.1.4 CEM User Stub Functions.

With this release, the CEM Header and Library Files support CEM User Stub Functions. Refer to Section 4 in this document for a full description of these Functions.

2.2 Problem Reports - None.

2.3 CEM Help

Usage: long nLineNumber;

Description: This Macro causes the Long Variable nLineNumber to be set to the Line Number (within the Current ATLAS Module Source File) of the Current ATLAS Statement .

If an error is detected or if the Current Line Number is not available, nLineNumber will be set to zero.

Usage: char *pcModuleName;

Description: This Macro causes the Character Pointer pcModuleName to be set to a pointer to a Character Array which contains the Current Module Name (as specified in the BEGIN ATLAS Statement).

If an error is detected or if the Current Module Name is not available, pcModuleName will be set to a Null Pointer.

Usage: long nStatementNumber;

Description: This Macro causes the Long Variable nStatementNumber to be set to the Statement Number (within the Current ATLAS Module) of the Current ATLAS Statement .

If an error is detected or if the Current Statement Number is not available, nStatementNumber will be set to a negative value (currently minus one (-1)).

Usage: short nVerb;

Description: This Macro causes the Short Variable nVerb to be set to the Verb Mnemonic that represents the Current ATLAS Statement Verb.

Verb Mnemonics are of the form V_XXX (e.g., V_APP for "APPLY") and may be found in the PAWS-generated CEM Header File key.h.

If an error is detected or if the Current Verb is not available, nVerb will be set to zero.

Usage: struct DATUM *psDatum;

Usage: struct DATUM *psDatum;

2.4 CEM User Stub Functions.

2.4.1 Overview

CEM User Stub Functions have been created in response to Customer requests and to TYX in-house testing requirements. The primary purpose of these Functions is to print CEM Kernel information (available to CEM Drivers) in a form that will assist the Programmer in writing a CEM Driver. Additionally, for those situations when the RTS is expecting a response from the CEM Module, the appropriate CEM User Stub Function will provide one.

These Functions also allow a Programmer to quickly create a dummy CEM Module. Testing with a dummy CEM Module is generally better then testing with simulated Busses and Devices because:

• It forces the RTS to execute its non-simulation code.

• The Operator does not have to enter simulated Device input (which works fine as long as the ATLAS Test Program does not attempt to "verify" the input).

Note There is a small possibility that at some future time the response capability will be enhanced to remove this limitation.

To create an ATLAS Test Program and CEM Module that can be executed by the RTS, the Programmer must create, as a minimum, the following Files:

• ATLAS Test Program Source File.
• Device Database Source File.
• CEM C Language Source File.
• Device Database Definition File.
• Bus Configuration File.

To fully complete the package, the Programmer may also create the following Files:

• Switch Database Source File.
• Interface Adapter Source File.

All builds are then done normally, including the CEM Module build.

2.4.2 Enabling.

All CEM User Functions have the same syntax: they are "int" Functions that take no Arguments. The CEM User Stub Functions conform to this syntax and they all return zero (0). (The CEM Kernel completely ignores the return value.)

There are CEM User Stub Functions for all CEM Non-ATLAS and ATLAS Actions, and they may be enabled in one of two ways, either:

• By specifying a CEM User Stub Function in the Device Database Definition File (which will completely "stub out" that particular Action); or

• By directly calling a CEM User Stub Function from within an existing CEM User Function.

Note Programmers must make sure that a particular CEM User Stub Function is enabled only for the CEM Action for which it is designed. If a CEM User Stub Function is enabled for a CEM Action for which it is not designed, the least problem is that the displayed information will be erroneous, and the worst possible problem is that the CEM User Stub Function will cause a fault.

Note The Functions specified for each Device/Channel's RESET ATLAS Action are also called immediately after the INTERFACECLEAR Non-ATLAS Action occurs and immediately before the DEVICECLEAR Non-ATLAS Action occurs.

2.4.3 Processing.

The bulk of the processing performed by the CEM User Stub Functions consists of acquiring information from the CEM Kernel, converting it to a form that is meaningful to a CEM Driver Programmer, and printing it. This processing is discussed in the Section on formatting below. However, there is some processing which is peculiar to the CEM User Stub Functions (i.e., something a CEM Driver would not do) and that processing is discussed in this Section.

userStubNaaINTERRUPT Prints information only the first time it is called.

userStubCONNECT Loops through and prints all Values of Connect-qualified Data.

userStubDISCONNECT Loops through and prints all Values of Disconnect-qualified Data.

userStubFETCH Loops through and stores a value in every Data Value of the Fetch-qualified Datum. (If the Datum Data Type is DIGITAL, a value is stored in every Data Value Byte.) Although these values are not strictly random (the first value stored is 1, the second is 2, the third is 3, etc.), from the standpoint of the ATLAS Test Program, they are effectively random. Loops through and prints all Values of the Fetch-qualified Datum.

userStubLOAD Loops through and prints all Values of the Load-qualified Datum.

userStubSETUP Loops through and prints all Values of all Data (except for Connect-, Disconnect-, Fetch- and Load-qualified Data) of all Modifiers for the Current Device/Channel.

2.4.4 Formatting.

CEM User Stub Functions print two types of Lines: Action Lines and Modifier Data Lines.

Every CEM User Stub Function prints an Action Line. Only the following ATLAS Action CEM Stub Functions print Modifier Data Lines: CONNECT, DISCONNECT, FETCH, LOAD and SETUP.

2.4.4.1 Formatting - Action Lines.

Action Lines have the following format:

CemStub hh:mm:ss DevChan/FncId Statement Signal Action BusAddr