The purpose of this document is to provide information pertaining to the release of the CEM Kernel and user interface. This document is divided into three sections:

Enhancements Describes changes that enhance the capability of the CEM Kernel.

Problem Reports Describes changes that correct errors reported in problem reports.

CEM Help Describes changes made to the user interface that will eventually be added to the CEM On-Line Help.

The RTS and CEM communicate using a Client/Server protocol based on the IEEE-488 Protocol. When the RTS desires to get data from the CEM (e.g., a Fetch or Status Request), the sequence of Messages between the RTS and CEM are:

The "listen" Command contains the Device/Channel information used by the CEM Kernel to call the appropriate CEM Device Driver ATLAS Action User Functions. If the Device/Channel information is invalid (usually as a result of a programming error), the CEM Kernel generates an Error Message.

Prior to this release, the CEM Kernel would also generate an Error Message if the "talk" Command contained invalid Device/Channel information. This resulted in continual Error Message being generated when the RTS was attempting (via Status Requests) to acquired queued Error Messages, thereby causing an infinite loop that could only be stopped by the Operator aborting the RTS manually (i.e., outside of the RTS).

With this release, the CEM Kernel no longer generates an Error Message if the "talk" Command contains invalid Device/Channel information. This scheme works because Device/Channel information is not used during the processing of either the "talk" Command or the Read processing (when the CEM Kernel is simply sending data (previously provided to the CEM Kernel by CEM Device Drivers) to the RTS).

The CEM Kernel is responsible for converting Datum Decimal Values (specified by CEM Device Drivers) to ASCII Strings for transmission to the RTS.

Prior to this release, the CEM Kernel converted these Values to "Decimal Strings" in the form:

Given that the various Floating-Point Formats supported by PTE and CEM contain only enough bits to provide accuracy to about 15 or 16 digits, this format caused no problems for Values in the range: 10**-15 <= Absolute Value <= 10**+15 because the Character Array used during the conversion contained over 100 Characters. Additionally, reasonable Values that fell outside of this range caused no real problems either (even though the Decimal String became longer and longer). However, extremely large or small Values (possibly caused by a software error that results in an invalid Floating-Point Number) would cause the Decimal String to overflow the Character Array.

With this release, the CEM Kernel converts these Values to "Exponential Strings" in the form:

The CEM Kernel contains (as does most TYX software) various safety checks for the detection of software errors. When one of these safety checks fails, the CEM Kernel sends a "Programming Error" Error Message to the RTS.

Prior to this release, WCEM Kernel Programming Error Messages contained the Error Number 30.

With this release, WCEM Kernel Programming Error Messages contain the Error Number 19. This change has been made in order to prevent the WCEM Kernel from using any Error Numbers within the 20 to 49 range to which the Studio RTS has assigned certain actions.

The purpose of the CONNECT Non-ATLAS Action is to inform the CEM Module that the RTS is "connecting" to the CEM Module and thereby allow the CEM Module to perform any first-time processing. Conversely, the purpose of the DISCONNECT Non-ATLAS Action is to inform the CEM Module that the RTS is "disconnecting" from the CEM Module and thereby allow the CEM Module to perform any last-time processing. URTS and WRTS cause these Actions to occur only once per loading/unloading of the CEM Module, regardless of the number of "Bus Channels" defined in the Bus Configuration File. However, the Studio RTS attempts to cause these Actions for each defined "Bus Channel" because the Studio RTS supports multiple DLL’s. There is no problem as long as these multiple DLL’s are different DLL’s, but there is a problem if any of these DLL’s are identical.

Prior to this release, the WCEM Kernel did not suppress multiple attempts to cause these Actions.

With this release, the WCEM Kernel allows the first CONNECT Non-ATLAS Action to occur, but suppresses any additional attempts. Conversely, the WCEM Kernel suppresses all but the last DISCONNECT Non-ATLAS Action.

The purpose of the OPEN Non-ATLAS Action is to inform the CEM Module that the RTS is opening Instrument Busses and thereby allow the CEM Module to perform any Instrument Bus open processing. Conversely, the purpose of the CLOSE Non-ATLAS Action is to inform the CEM Module that the RTS is closing Instrument Busses and thereby allow the CEM Module to perform any Instrument Bus close processing. URTS and WRTS cause these Actions to occur only once per opening/closing of the Instrument Busses, regardless of the number of "Bus Channels" defined within the Bus Configuration File. However, the Studio RTS attempts to cause these Actions for each defined "Bus Channel" because the Studio RTS supports multiple DLL’s. There is no problem as long as these multiple DLL’s are different DLL’s, but there is a problem if any of these DLL’s are identical.

Prior to this release, the WCEM Kernel did not suppress multiple attempts to cause these Actions.

With this release, the WCEM Kernel allows the first OPEN Non-ATLAS Action to occur, but suppresses any additional attempts. Conversely, the WCEM Kernel suppresses all but the last CLOSE Non-ATLAS Action.

None.

None.