OASIS-CC VERSION V02.05.09 RELEASE NOTES TABLE OF CONTENTS 1 Compatibility Information 2 OASIS-CC Installation Procedure 3 Upgrading V02.05.08 Applications to V02.05.09 4 New Features Or Code Fixes 4.1 Improved command generation capability (CRN 309) 4.2 Fix to database report output (CRN 242) 4.3 New Command Execution Verification (CEV) Mechanism (CRN 308, OSCAR 39) 4.4 Unexpected Event Detection (UED) (CRN 310. OSCARs 39 and 29) 4.5 New Special Global Variables (CRN 308, CRN 310 and 324, OSCAR 16) 4.6 Support for 1553 Low Rate Science (EOS/am) Remote Terminal Mode (CRN 322, OSCAR 6) 4.7 Direct ASCII Commanding (CRN 325, OSCAR 45) 4.8 Additional Command Sub-Language Directives (CRN 330) 4.9 New DN to EU Conversions (OSCAR 20, CRN 328) 4.10 Improved Wait Statement (OSCAR 23, CRN 329) 4.11 ASCII Strings To Bridge (CRN 343) 4.12 RUN Directive Works (CRN 339) 4.13 Display Of TAE Panels On Remote X-11 Terminals (OSCAR 37, CRN 344) 4.14 New Recording Format (CRN 278, CRN 350) 4.15 Procedure Goes In Indefinite Wait If Hazardous Command Rejected (CRN 327) 5 Change Requests Closed With This Release 6 Main Known Problems And Limitations 6.1 Filename Length Limitation 6.2 Limited thruput while using a generic communication protocol with a TDM frame (CRN 259) 6.3 Badly formatted internet address hangs OASIS-CC (CRN 258) 6.4 Clearing a panel with a selection list presentation type with a scrolling bar can cause OASIS-CC to crash (CRN 252) 6.5 When an IP server stream is switched on, OASIS-CC keyboard or procedure input processing can become locked (CRN 294) 6.6 Double precision floating point printout may be incorrect (CRN 320) 6.7 Highlighted item on a selection list is unchoosable (CRN 265) 6.8 S11W implementation not available in the SOLARIS version 6.9 CEV may fail if CEV_TIMEOUT is greater than 86400.0 seconds (CRN 358) 6.10 Initialization problem with keyed binary bridge (CRN 359) 6.11 Apparent memory leak in graph presentation type (CRN 337) 7 Anomaly Or Enhancement Request Reporting 8 Documentation Set Status 9 Upgrades To The Spectrometer Application Appendix A: DATABASE TABLE LAYOUT Appendix B: CSTOL CHANGES Appendix C: 1553 RT USER'S GUIDE Appendix D: THRUPUT MEASUREMENT Appendix E: IEEE-448 USER'S GUIDE Appendix F: PARSER UPDATE COOK BOOK Appendix G: RAW DATA FORMAT (PREVIOUS RELEASES) Appendix H: RAW DATA FORMAT (V02.05.09 AND UP) Appendix I: OASIS-CC PROCESSING OF "ERRONEOUS" DATA Appendix J: SYNC PATTERN, BLOCK ID, ETC... Appendix K: SOLARIS VERSION STATUS OASIS-CC VERSION V02.05.09 RELEASE NOTES 12/15/93 These release notes describe version V02.05.09 of OASIS-CC. A copy of these notes can be found in $ODIST/release_notes/oasis_v2.0509. A copy of the notes from previous releases can also be found in the $ODIST/release_notes directory. Version V02.05.09 presents numerous improvements from V02.05.08: (1) It allows the specification of command subfield values with the range and precision of IEEE-754 64-bits floating point numbers, and the generation of binary commands where subfields can be formatted as integer, IEEE-754 32-bits floating point or IEEE-754 64-bits floating point; (2) It provides a new command execution verification mechanism and a way to detect unexpected events; (3) It provides a capability to directly send ASCII strings to external elements; (4) The wait statement is also improved; (5) Character strings can now be passed to a bridge; (6) TAE panels can be displayed on remote X-11 terminals. This release comes in 2 flavors: a SunOs 4.1.x version and a SOLARIS 2.2 version. The SOLARIS 2.2 uses TAE+ 5.2 for SOLARIS which is only available to the EOS am program. Note that Appendix K gives a brief overview of the SOLARIS version status. 1 Compatibility Information ----------------------------- This release of OASIS-CC has been tested under the following conditions: Sparcstation IPC and 2 SunOS 4.1.1 and 4.1.3 X MIT X11R4 with fixes 1 to 18 MOTIF 1.1.4 TAE+ 5.2 Sparcstation 2 SOLARIS 2.2 X X11R5 from BlueStone MOTIF 1.2 from BlueStone TAE+ 5.2 for SOLARIS Note that for the SunOs distribution: (1) The Ada distributions require SunAda 1.1; (2) All the distributions require the MOTIF developer's kit; (3) OASIS-CC cannot be linked with shareable libraries. For example, OASIS-CC needs the libXm.a motif library. It cannot be linked with the libXm.so motif library; Note that for the SOLARIS distribution: (1) The Ada distributions require SunAda 2.0; (2) The C distribution requires a C compiler (OASIS-CC was tested using the Sun C SparCompiler. The make_oasis_app.sh utility requires the Sun C SparCompiler. It needs to be updated for use with other compilers such as the GNU C compiler); (3) OASIS-CC was tested with X and MOTIF from BlueStone; 2 OASIS-CC Installation Procedure ---------------------------------- SunOs Distributions ------------------- Refer to the Unix OASIS-CC V02.05.09 Installation Guide for instructions on how to install the OASIS-CC software from the tar tape. Sites that require the ability to maintain applications running under previous releases must install V02.05.09 in a new directory. SOLARIS Distributions --------------------- Refer to the Unix OASIS-CC V02.05.09 Installation Guide for instructions on how to install the OASIS-CC software from the tar tape. ******************************************************************************* * We recommend that you run OASIS-CC in the SOLARIS RT (realtime) scheduling * * class rather than the SOLARIS TS (time-sharing) scheduling class. Also, as * * OASIS-CC uses shared libraries, we recommend that you set the environment * * variable LD_BIND_NOW to a non-NULL value (ref: SunOs 5.2 System Services, * * page 188). * ******************************************************************************* 3 Upgrading V02.05.08 Applications to V02.05.09 ------------------------------------------------ SunOs Distributions ------------------- There are changes in the OASIS-CC V02.05.09 code that makes this release incompatible with applications running version V02.05.08. The changes are: (1) The commands, command_values, ascii_command_values, ascii_command_maps, command_value_conversions, latest_data, links and the analog_conversions tables format has been modified (See Appendix A for a description of the new layout of the tables); (2) The CSTOL language has been expanded, so there is a new parser table (See Appendix B for a description of the language extensions). Sites that require the ability to maintain version V02.05.08 or earlier release applications will need new accounts for their associated V02.05.09 applications. The paragraph "Creating OASIS-CC Accounts" in the Unix OASIS-CC V02.05.09 Installation Guide provides details on the requirements for application accounts. The OASIS-CC Application Environment Reference Manual describes how to create the appropriate application environment. The minimum set of files that users need to transfer from existing applications to the areas for developing applications with the new release are: OASIS Database files OASIS Procedure files OASIS Macro files TAE+ resource and graphics files The distribution tape contains a command procedure (v020508to09) that will make a V02.05.08 application compatible with V02.05.09. To upgrade to V02.05.09, perform the following: (1) Log in the application account intended for V02.05.09 development. This account should be populated with V02.05.08 files (the minimum set is listed above). (2) Set up all the environment variables. Make sure that ODIST points to the OASIS-CC V02.05.09 distribution and that TAE points to the TAE+ 5.2 distribution. (3) Execute the OASIS-CC upgrade by typing: $ODIST/bin/v020508to09.csh (5) Re-create your application. To update from a version prior to V02.05.08, you must first upgrade to V02.05.08. Refer to the release notes in $ODIST/release_notes. NOTE: If you populate your command database via CSTOL procedures, you need to update all insert or update statements for the following tables: command_values In the insert statement for the command_values table, the values for the field max_value, min_value, default_value needs to be changed from integer to float (for example min_value = 32 needs to be changed to min_value = 32.0). SOLARIS Distributions --------------------- The distribution tape contains a command procedure (v020508to09) that will make a V02.05.08/SunOs application compatible with V02.05.09. To upgrade to V02.05.09, perform the following: (1) Using the v020508 dump_database utility, dump all your tables (you have to do that on a SunOS machine). (2) Log in the application account intended for V02.05.09 development. This account should be populated with V02.05.08 files (the minimum set is listed above). (3) Set up all the environment variables. Make sure that ODIST points to the OASIS-CC V02.05.09 distribution and that TAE points to the TAE+ 5.2 distribution. (4) Transfer all the .dump files created in step 1 to the $OASIS_DATABASE directory on the SOLARIS machine. (5) Execute the OASIS-CC upgrade by typing: $ODIST/bin/v020508to09.csh (6) Re-create your application. NOTE: If you populate your command database via CSTOL procedures, you need to update all insert or update statements for the following tables: command_values In the insert statement for the command_values table, the values for the field max_value, min_value, default_value needs to be changed from integer to float (for example min_value = 32 needs to be changed to min_value = 32.0). 4 New Features Or Code Fixes ------------------------------ The following new features and major code fixes are included in this release. New features and code fixes have associated Change Request Numbers (CRNs) that provide a means of tracking changes to the OASIS-CC code. CRNs are generated by LASP and the general OASIS-CC user community. The pertinent CRNs are shown for each enhancement or correction included in this new version of OASIS-CC. 4.1 Improved command generation capability (CRN 309) --------------------------------------------------- With this upgrade users can now express command subfield values with the range and accuracy of an IEEE-754 64-bit floating point number. In previous OASIS-CC releases, binary command subfields could only be formatted as integer numbers (from 1 bit to 32 bits long). With this upgrade they can be formatted as integer numbers (from 1 bit to 32 bits long), IEEE-754 32-bits floating point numbers or IEEE-754 64-bits floating point numbers. 4.2 Fix to database report output (CRN 242) ------------------------------------------- In previous OASIS-CC, when the X dimension of the report window is set to 68 (as used in the starter application and in many other application), the last character of some lines is overwritten, making the report confusing. With this release the problem is avoided by formatting the report lines over 67 characters. Therefore database reports should now be Ok, as long as the X dimension of the report window is at least 68 characters. Note that the report code does not access the current dimension of the report window when a report is created. It assumes that the report window is 68 characters wide. Note also that when a field output is greater than 67 characters, it is truncated to its first 67 characters. 4.3 New Command Execution Verification (CEV) Mechanism (CRN 308, OSCAR 39) ------------------------------------------------------------------------- This release introduces a new mechanism to verify command execution. This mechanism, called Command Execution Verification or CEV, does not replace the current command post-check. However if both execution verification mechanisms are enabled, only CEV is executed. In the command post-check capability a command is associated with the measurements that should reflect the command execution via a CSTOL procedure. In the CEV the association is via the commands table. The commands table (see Appendix A) now contains two fields (CEV_EXTERNAL_ELEMENT, CEV_ITEM_NAME) that point back in the latest data table to one measurement (either a real or a pseudo measurement) which raw value or raw value bit pattern can be used to verify that the command has executed. The commands table new field CEV_VALUE contains the value that the 32 least significant bits (DN_LOW) of the measurement should have after the command has executed. The commands table new field CEV_MASK masks the bits that should be set in the 32 least significant bits (DN_LOW) of measurements after the command has executed. If CEV_MASK is set to zero, then OASIS-CC uses CEV_VALUE to verify the command. Otherwise it uses CEV_MASK. The commands table new field CEV_TIMEOUT indicates the amount of time OASIS-CC should wait for command verification before declaring a command verification failure. When a command for which CEV is enabled is successfully sent, it is put on a pending verification queue. Every time new data is received by OASIS-CC, a verification check is done. If the command verifies, a message is output like: 93/272-12:00:00 CI Command GRATING, SET_POSITION_5 has executed If the command failed execution verification, a warning message is printed like: 93/272-12:00:00 CW Command GRATING, SET_POSITION_5 has failed execution verification At any time the user can access the status of the CEV by entering the new CSTOL statement (see Appendix B) "SHOW PENDING CEV". This results in messages like: 93/275-13:37:27 LP_U (CRN_308_A) show pending cev 93/275-13:37:27 CI 4 commands are pending, 0 commands have failed system wide 93/275-13:37:27 CI 3 commands are pending, 0 commands have failed in group AA 93/275-13:37:27 CI 1 commands are pending, 0 commands have failed in group BB 93/275-13:37:27 CI Command GRATING, SET_POSITION_2 has 20.0570 seconds before timeout 93/275-13:37:27 CI Command GRATING, SET_POSITION_3 has 3.2710 seconds before timeout 93/275-13:37:28 CI Command GRATING, SET_POSITION_4 has 15.4510 seconds before timeout 93/275-13:37:28 CI Command GRATING, SET_POSITION_5 has 0.6880 seconds before timeout This release also provides the capability for a cstol procedure to wait for a command to execute or a group of commands to execute before stepping to the next statement. For that purpose three new cstol directives have been introduced (see Appendix B): WAIT FOR LAST blocks the procedure until the last command sent from the clp on which the procedure is executing verifies. If the command does not verify, the procedure stays blocked and a red (blocking) error message is printed: 93/272-12:20:05 LE_U Command execution verification failed WAIT FOR ALL blocks the procedure until all the commands that have been send since the CEV state has been reset (see below) have executed. If one or more command don't verify the procedure stays blocked and a red (blocking) error message is printed: 93/272-12:20:05 LE_U (proc name) Command execution verification failed for all groups For the purpose of execution verification, commands can be logically grouped (see the new commands table field CEV_GROUP) so as to block a procedure until all the commands for a group that have been sent have executed. This is done via the WAIT FOR cstol directive. If one or more commands from a group don't verify the procedure stays blocked and a red (blocking) message is printed: 93/272-12:20:05 LE_U (proc name) Command execution verification failed for group AA After a WAIT FOR ALL directive, all CEVs are reset. After a WAIT FOR , all CEVs for the group are reset. Similar effect can be obtained with the CSTOL directives FLUSH ALL and FLUSH . Note that the functionality described above also applies to multiple commands blocked into one command message. Note on setting the CEV_TIMEOUT value: the time out timer starts to decrement at the moment the command is ready to be passed to the transmitter task. This can be some milliseconds before the command is received by the external element. How many milliseconds depends on numerous factors such as OASIS-CC processing load and transmission delays. 4.4 Unexpected Event Detection (UED) (CRN 310, OSCARs 39 and 29) --------------------------------------------------------------- In parallel to the new CEV capability, this release introduces a mechanism to detect unexpected events. An unexpected event is defined as a change in the value of a measurement when none of the commands that should result in a change in the value of the measurement have been sent. When OASIS-CC detects that a measurement for which UED is enabled (see Appendix A for a description of the new field UED_ENABLED in the latest_data table) has changed value, it checks if any commands related to the measurement via the CEV capability are on the pending verification queue. If the check is negative, a red (non blocking) error message is printed in the message log, like: 93/275-13:37:27 HU GRATING SET_POSITION_2 : Unexpected event detected ******************************************************************* * Note the new message identification code HU that indicates this * * type of messages. * ******************************************************************* UED can only be detected on raw value or on state value (as state values are converted back to a raw values by OASIS-CC) because CEV works only on raw values UED supposes that CEV is enabled. For example if CEV is disabled for a command and if UED is enabled for the measurement associated with the command, then every time the measurement changes value an error will be reported because the command will never be put on the pending verification queue. 4.5 New Special Global Variables (CRN 308, CRN 310 and 324, OSCAR 16) -------------------------------------------------------------------- Four new special variables have been introduced to control, at the system level, unexpected event detection, command execution verification, command pre-check and command post-check. Like the special global variables introduced in V02.05.07 ($$STATE_MODES, $$LIMITS_MODE and $$GBL_COMMAND_MODE) they are shared by all OASIS-CC subsystems and they update predefined latest_data entries. $$UED_MODE This variable can take the value ON or OFF. When OFF unexpected event detection is disabled. When ON unexpected event detection is enabled for all measurements with UED_ENABLED = TRUE in the latest_data table. The latest_data entry $$GLOBAL $$UED_MODE is associated with the $$UED_MODE special variable. $$CEV_MODE This variable can take the value ON or OFF. When OFF command execution verification is disabled. When ON command execution verification is enabled for all commands with DO_CEV = TRUE in the commands table. The latest_data entry $$GLOBAL $CEV_MODE is associated with the $$CEV_MODE special variable. $$PRECHECK_MODE This variable can take the value ON or OFF. When OFF command pre-check is disabled. When ON command pre-check is enabled for all commands with DO_PRECHECK = TRUE in the commands table. The latest_data entry $$GLOBAL $$PRECHECK_MODE is associated with the $$PRECHECK_MODE special variable. $$POSTCHECK_MODE This variable can take the value ON or OFF. When OFF command post-check is disabled. When ON command post-check is enabled for all commands with DO_POSCHECK = TRUE in the commands table. The latest_data entry $$GLOBAL $$POSTCHECK_MODE is associated with the $$POST_CHECK_MODE special variable. ************************************************************************** * See also paragraph 4.10 for a description of the variables $$ERROR and * * $$CHECK_INTERVAL. * ************************************************************************** Support for 1553 Low Rate Science (EOS/am) Remote Terminal Mode ------------------------------------------------------------------- (CRN 322, OSCAR 6) This release of OASIS-CC provides a Remote Terminal implementation of the EOS/am 1553 low rate science protocol. It can be used to transfer to a Bus Controller data routed from another I/O port or data directly read from a file. Appendix C provides a short user's guide (including the current limitations) for this implementation. 4.7 Direct ASCII Commanding (CRN 325, OSCAR 45) ----------------------------------------------- This new capability allows the user to send ASCII strings, bypassing most of the command subsystem protection. It parallels the "raw" bit pattern capability already existing in OASIS-CC. Like the raw bit pattern command it is initiated by a SEND directive (such as SEND "this is a test" to (See Appendix B). Like the raw bit pattern capability, it expects one special record to be defined in the commands table. In absence of this record, OASIS-CC assumes that the capability is disabled for the external element to which the ASCII string is directed. The commands table record that is needed should have the following values: EXTERNAL_ELEMENT => name of the external element NAME => $$SEND_RAW_ASCII CMD_TYPE => as needed IS_IN_USE => system field IS_LEGAL_IN_REALTIME_MSG => as needed IS_LEGAL_IN_DELAYED_MSG => as needed IS_LEGAL_IN_PRIORITY_RQST => as needed LEGAL_SOURCE => as needed SAFETY_LEVEL => as needed IS_DISCRETE => FALSE IS_ASCII => TRUE LENGTH => if 0, the length of the string in the SEND statement is used. If /=0, this is the length (in number of characters) of the command that will be sent. If the string in the SEND statement is shorter, the rest of the command is padded with spaces. If the string in the SEND statement is larger, the string is truncated if so approved by the user in an alert window. FIXED_PATTERN => don't care all the other fields are "as needed" Note that the implementation allows quotes (") to be defined within quotes. This is done by substituing at "send time" a single quote (') with a double quote in the string. For example with send "LET STREAM FILE_NAME ='/mirza5/test/new_log.dat'" to remote_node the following character string will be sent to remote_node: LET STREAM FILENAME = "/mirza5/test/new_log.dat" The maximum length of the character string in a send directive is 256 characters. 4.8 Additional Command Sub-Language Directives (CRN 330) -------------------------------------------------------- Six new directives have been added to the command sub-language: ARM, DISARM, FIRE, INITIATE, ACTIVATE and GET. 4.9 New DN to EU Conversions (OSCAR 20, CRN 328) ----------------------------------------------- In addition to the current segmented third degree polynomial conversion, this release also offers UNSEGMENTED fifth degree polynomial conversion (eu = c0 + c1 * dn + c2 * dn**2 + c3 * dn**3 + c4 * dn**4 + c5 * dn**5) and UNSEGMENTED exponential (eu = c0 + c1 * exp (c2 * dn)) conversion. The new layout of the analog_conversions table is described in Appendix A. Note that in the case of UNSEGMENTED conversions, OASIS-CC looks for a record with the SEGMENT field set to 1. 4.10 Improved Wait Statement (OSCAR 23, CRN 329) ------------------------------------------------ This release allows the user to define the maximum amount of time at which a procedure at a conditional wait statement should stay blocked. A special variable called $$ERROR can be tested to examine the reason for which the procedure became unblocked. It can take the value of NO_ERROR or TIME_OUT. NO_ERROR indicates that the condition in the conditional expression has been met, while TIME_OUT indicates that the condition has not been met during the delay indicated in the wait statement. The following is an example (the CSTOL language extensions are detailed in Appendix B) wait platform position = 200.0 deg or for 00:00:10.0 if $$ERROR = TIME_OUT ; value if after 10 s platform position has not ; been equal to 200.0 deg write "Platform in error" wait endif There is one $$ERROR special variable per clp. Note that the wait statement can still exit with a blocking red error message in case a problem occurs during the evaluation of the conditional expression. Until V02.05.08, a conditional expression in a wait statement was re-evaluated every second. In this release, the delay between the evalution of the conditional expression can be adjusted via a new special variable called $$CHECK_INTERVAL. There is one $$CHECK_INTERVAL special variable per clp. It is of the type "delta time" and it's default value is 00:00:01.0. Example: let $$CHECK_INTERVAL = 00:00:00.5 ; next condition in wait will be ; rechecked every 0.5 second wait raw PC SRQ_BIT = 1 dn Note that in the example above, if "pc srq_bit" changes rapidly, the condition "raw pc srq_bit = 1 dn" may never evaluate to TRUE even if $$CHECK_INTERVAL is very small. This is because the evaluation of the conditional expression occurs asynchronously to the data. However if the data does not change rapidly (for example a SRQ bit set by an IEEE device), the $$CHECK_INTERVAL controls the delay between the condition being met and OASIS-CC being aware of it. 4.11 ASCII Strings To Bridge (CRN 343) ------------------------------------- ASCII strings can now be passed to a bridge stream. The tables below show valid combinations of the fields TYPE_OF_DATA (in the bridge definitions table) and DATA_CLASS (in the latest_data table) and their results in the v020508 version (table 4.11.1) and in this release (table 4.11.2). DATA_CLASS | NUMERIC STATE CHARACTER_STRING TYPE_OF_DATA | ------------------------------------------------------------------------------- DN_DATA | DN_LOW ILLEGAL ILLEGAL EU_DATA | EU DN_LOW ILLEGAL SMOOTHED_DATA | EU_SMOOTHED ILLEGAL ILLEGAL TREND_DATA | EU_RATE_OF_CHANGE ILLEGAL ILLEGAL -- table 4.11.1 -- DATA_CLASS | NUMERIC STATE CHARACTER_STRING TYPE_OF_DATA | ------------------------------------------------------------------------------- DN_DATA | DN_LOW DN_LOW* CHAR_STRING EU_DATA | EU EU_STATE CHAR_STRING SMOOTHED_DATA | EU_SMOOTHED EU_STATE CHAR_STRING TREND_DATA | EU_RATE_OF_CHANGE EU_STATE CHAR_STRING *: unlike display_definitions, where EU_STATE is displayed -- table 4.11.2 -- The format to use in the bridge definition table to output character strings is "An" (in an ASCII bridge) or "TBn" (in a Binary bridge). N indicates the number of characters to be used for the A format or the number of bit to be used for the TB format. In the case of the TB format, n must to be multiple of 8. If the output is too long or too short it is truncated or padded with ascii "space". 4.12 RUN Directive Works (CRN 339) ---------------------------------- The RUN directives has been fixed. The following rule was implemented for the interpretation of the task_file_name field in the utility_tasks table: - If the task_file_name starts with a $, what's in between the $ and the first / is uppercased and interpreted as an environment variable. - All the rest of the contents of the task_file_name is put to lowercase. ****************************************************************** * * * The length of the task filename including the full pathname is * * limited to 60 characters. * * * * If the child process terminates almost immediatly after it * * is spawned, OASIS-CC reports an error. * * * * Under SOLARIS, the child process runs in the same scheduling * * class and priority as OASIS-CC. * * * ****************************************************************** Note that the RUN directive expects a description of the window to be used by the child process in the display_descriptions table under the page_name of DCL_WINDOW. If the DCL_WINDOW record is not present, the RUN directive inserts its own with following values: page_name=DCL_WINDOW page_kind=FOR_ALERT workstation_type=DCL_WS description= is_inout=FALSE background_color=BACKGROUND text_color=FOREGROUND border=FALSE title_flag=FALSE title=DCL_WINDOW lower_left_corner_x=0 lower_left_corner_y=44 x_dimension=80 y_dimension=24 number_of_next_line=0 discriminator= tae_panel_name= 4.13 Display Of TAE Panels On Remote X-11 Terminals (OSCAR 37, CRN 344) ----------------------------------------------------------------------- TAE panels can be displayed on remote X-11 terminals. The cstol directives DISPLAY and CLEAR have been modified to support this function. They now take the following syntax: DISPLAY xyx TO remote_terminal_nickname CLEAR yxz FROM remote_terminal_nickname CLEAR all displays FROM remote_terminal_nickname where remote_terminal_nickname is a 16 character (max) identifier of the remote terminal. The nickname should point to a links table record. Within the links table record, the field data_line should contain the full internet name of the remote terminal. The following rules apply to the nickname: - If the nickname does not point to a links table record, it is used as a full internet name (i.e., we assume that the remote terminal is on the same internet domain as the local computer). - Otherwise, the contents of the data_line field is used as the internet address (note that the data_line field has been expanded from 16 characters to 128 characters). - If no terminal address (i.e. ":0.0") is appended to the internet address, OASIS-CC appends ":0.0". - OASIS-CC does not check the syntax of the internet address. Actions performed on the remote panels, such as clear button or display button, are performed locally. ******************************************************************************** * * * There are several limitations that you should be aware of: * * * * - If after you have displayed one or more panels on a remote X-11 terminal * * the X-11 server is killed on the remote terminal OASIS-CC crashes even if * * all the tae panels have been cleared from the remote X-11 terminal before * * the server is terminated. Note that this is not an OASIS-CC problem. * * * * - Assume that you have a panel with an input field and that this panel is * * displayed on two screens. If simultaneously two users enter something in * * the input field the result is unknown (basically TAE creates only one * * structure per defined panel to save the user input and not one structure * * per displayed panel). * * * ******************************************************************************** 4.14 New Recording Format (CRN 278, CRN 350) -------------------------------------------- As indicated in previous release notes, the recording format of the raw data was dependent on the compiler make, and even the compiler version within the same make. This caused serious problems. With this release, the format has been stabilized. It is not compatible with the format generated by previous releases. If needed a small utility can be developed to go from one format to another (contact the OASIS-CC office at CU/LASP if needed). Appendix G describes the formats that were generated by previous releases. Appendix H describes the current format. Note to the users of the "Ada extendable object" distribution or of the "Ada source" distribution: the changes in the recording format have necessitated some modifications to the specfications of OASIS_SYSTIME_KEYED_IO package. The old OASIS_SYSTIME_KEYED_IO package is still available in the Ada distributions under the name of OASIS_SYSTIME_KEYED_IO_OLD. The specifications of the new package are: -- Copyright 1986, 1992 by the Regents -- of the University of Colorado -- Generic file IO package with system keyed recording and retrieval of records -- Updated from original version (by tps 1985) by aj per crn 350 ------------------------------------------------------------------------------- with Sequential_Io, Calendar, Byte_Oriented_Extcomm_Tools; use Byte_Oriented_Extcomm_Tools; generic First : INTEGER; Last : INTEGER; package Oasis_Systime_Keyed_Io is use Dissolution; type READ_STATUS is private; type FILE_HOLDER is limited private; type OPEN_TYPE is (READ, WRITE); END_OF_RETRIEVE : exception; procedure File_Open (File_Name : in STRING; Open_How : in OPEN_TYPE; File : in out FILE_HOLDER); procedure File_Position (File : in out FILE_HOLDER; Time_Pointer : in Calendar.TIME); procedure File_Retrieve (File : in out FILE_HOLDER; Stop_Time : in Calendar.TIME; Data_Quality : out INTEGER; -- 0: GOOD, =/0 BAD Data_Size : out INTEGER; -- valid size of buf. Data_Time : out Calendar.TIME; Current_Record: out BYTE_BUFFER); procedure File_Record (File : in out FILE_HOLDER; Data_Quality : in INTEGER; --0: GOOD, =/0 BAD Data_Size : in INTEGER; --valid size of buf Current_Record: in BYTE_BUFFER); procedure File_Close (File : in out FILE_HOLDER); private Offset : constant INTEGER := 25; -- 1 + 24. 24 = 4 of year + 4 of month + 4 of day + 4 of tenth of mill + -- 4 of Quality + 4 of valid size Version_Number : constant INTEGER := 1; Record_Length : constant INTEGER := Last - First + Offset; subtype RECORD_TYPE is BYTE_BUFFER(1..Record_Length); package Time_Key_Io is new Sequential_Io(RECORD_TYPE); type READ_STATUS is (OPENED,POSITIONED,READING,RECORDING,EMPTY); type FILE_HOLDER is record File_Id : Time_Key_Io.FILE_TYPE; Current_Time : Calendar.TIME; Data_Quality : INTEGER; Data_Size : INTEGER; Status : READ_STATUS := EMPTY; File_Record : RECORD_TYPE; end record; end Oasis_Systime_Keyed_Io; 4.15 Procedure Goes In Indefinite Wait If Hazardous Command Rejected (CRN 327) ----------------------------------------------------------------------------- When a hazardous command (or a command with an hazardous subfield) is requested from a procedure and is cancelled by the user, the procedure is put in an indefinited wait state. 5 Change Requests Closed With This Release -------------------------------------------- Change Requests Number: 173, 208, 222, 242, 308, 309, 310, 314, 316, 317, 318, 319, 320, 322, 323, 324, 325, 327, 328, 329, 330, 339, 341, 343, 344, 347, 350, 351 and 356. The following crns have also been closed with 3 patches of v020508: 202, 296, 297, 298, 299, 302, 304, 306 and 307. 6 Main Known Problems And Limitations --------------------------------------- 6.1 Filename Length Limitation ------------------------------ In OASIS-CC filenames can be up to 60 characters long. In the SOLARIS and the SunOS versions, the length of the pathname (not the length of the environment variable that translates into the pathname) is included in the filename length. Therefore, the 60 characters limit can be easily reached. A way around this limitation is to softlink the directories to directories with shorter names and define the environment variables relative to the new directories. 6.2 Limited thruput while using a generic communication protocol with a TDM --------------------------------------------------------------------------- frame (CRN 259) ------------------ The current implementation of the generic communication protocol provides the user with some flexibility in controlling the load put on the host machine by the data acquisition if the data comes as packets. Ideally, it would be nice to choose the time_out and frame_length parameters (in the streams table record describing the primary stream) such as frame_length/time_out >> bit rate. If the stream is packetized the only requirement on the frame_length is that it has to be greater than the largest of the packets. The larger the frame_length, the greater the time_out value can be and therefore the lower the load on the machine. Currently in the case of a TDM frame, the frame_length has to be equal to the length of the frame, which limits the possible values for the time_out parameter. 6.3 Badly formatted internet address hangs OASIS-CC (CRN 258) ------------------------------------------------------------ Putting a badly formatted internet address (such as "/128.32.33.34" instead of "128.32.33.34") in the data_line field of the links table for streams that use the IP protocol causes OASIS-CC to hang. 6.4 Clearing a panel with a selection list presentation type with a ------------------------------------------------------------------- scrolling bar can cause OASIS-CC to crash (CRN 252) ------------------------------------------------------ When clearing a panel with a selection list presentation type with a scrolling bar, seven error messages ("Warning: Cannot find callback list in XtRemoveAllCallbacks") are output in the startup window. Our analysis of the problem is that it may cause OASIS-CC to crash. A workaround is to hide the panel rather than clear it. NOTE THAT THIS IS FIXED IN THE SOLARIS VERSION. 6.5 When an IP server stream is switched on, OASIS-CC keyboard or ----------------------------------------------------------------- procedure input processing can become locked (CRN 294) ---------------------------------------------------------- When a server stream is started using the IP protocol, the task handling the stream first waits for a client process to connect. It is only after a connection has been established with a client process that task is able to execute processing directives, such as route or record. 6.6 Double precision floating point printout may be incorrect (CRN 320) ----------------------------------------------------------------------- When a local variable whose value is lower than 1.0e-99 is written or displayed the output is incorrect. For example 1.0e-100 appears as 1.0e-90, 1.0e-101 appears as 1.0e-91. This problem has been traced to a compiler problem and can be reproduced outside the OASIS-CC code. While the printed value is incorrect, the internal representation of the value seems to be correct. THIS PROBLEM OCCURS ONLY IN THE SUNOS VERSION. 6.7 Highlighted item on a selection list is unchoosable (CRN 265) ----------------------------------------------------------------- When a selection list panel comes up with an highlighted item, the item cannot be directly selected. NOTE THAT THIS IS FIXED IN THE SOLARIS VERSION. 6.8 S11W implementation not available in the SOLARIS version ------------------------------------------------------------ Because of driver problems the S11W code is not functional with SOLARIS version. This should be fixed when the new EDT driver is available (TBD). 6.9 CEV may fail if CEV_TIMEOUT is greater than 86400.0 seconds (CRN 358) ------------------------------------------------------------------------ When CEV_TIMEOUT is set to a value greater than 86400.0 seconds, a command may immediatly fail CEV, as if the CEV_TIMEOUT was set to 0.0. This is due to a SunAda compiler problem. 6.10 Initialization problem with keyed binary bridge (CRN 359) -------------------------------------------------------------- The problem occurs under the following conditions: (a) The bridge is a binary keyed bridge; (b) The "w" values in the TB[w] format don't follow the format rules (i.e "w" defaults to 32 for eu_data and to 96 for time_data, "w" is rounded to the nearest 8 bits and "w" is limited to 128 * 8 for character strings; and (c) non-key items are not recieved before the triggering key item is recieved. Then OASIS-CC may report an error in the "write_line" routine and it is possible that some of the first records are not correctly formatted. This problem can be avoided by using "w" values that follow the rules listed above. 6.11 Apparent memory leak in graph presentation type (CRN 337) -------------------------------------------------------------- The graph presentation gives the apparence of memory leak. This is because it was designed to update very rapidly without being concerned with memory deallocation except at certain times. This may need to be reconsidered in the future, but for now it is be necessary to know when memory is cleaned up in order to avoid the problem of memory continuing to be allocated. If you have a continuously updating graph, it will only have memory cleaned up when: 1) The panel is deleted. (not hidden). 2) A non-visible point is plotted and the graph is set to "jump" to the new point ("dojump" resource is TRUE). 3) The graph item is redrawn due to some change in its appearance. This may be anything including a title change, font change, color change, or anything which would require the items to be rearranged in the graph. 4) The graph area is redrawn by a user scrolling with scrollbars. Notice that continuously updating graphs which take a long time before a non-visible point is plotted (the end of the graph is reached) will continuously allocate memory without ever deallocating it. 7 Anomaly Or Enhancement Request Reporting -------------------------------------------- The mechanism previously used with the VMS version since 1988 to report OASIS-CC anomalies or to suggest enhancements to the OASIS-CC functionality has been extended to the SunOS version. The report generated using this mechanism can be sent to the OASIS project office by electronic mail (the preferred way) or by regular mail. Each report is assigned a Change Request Number (CRN) and is acknowledged to the originator. The CRN can be used to track progress on the report. To report an anomaly enter: $ODIST/bin/report.csh 8 Documentation Set Status ---------------------------- Documentation Changes for V020509 There are many documentation updates delivered with V020509. Most of these changes reflect enhanced OASIS-CC capabilities, but some of the changes are corrections or clarifications to previous documents. The updates are delivered as 'add ons', meaning that they are intended to replace portions of the existing documents (the quick Reference Guide is the only one delivered as an entire reprint). New cover pages and tables of contents are also provided. The changes are as follows: OASIS-CC System Manager's Guide (these updates should replace sections in the 'V02.05.08 and subsequent versions of June, 1993') New Title Pages New Contents Chapter 4 Entire reprint. Updated for new analog conversions and Unexpected Event Detection. Chapter 5 Entire reprint. Updated for Command Execution Verification, and raw ASCII commands. Chapter 6 Page 2. Removed Reference to IEEE_488 User's Guide. The documentation will be included in the Generic Communications User's Guide at some point in the fulture. Page 3 - Paragraph 3. Removed implication that command streams are recorded. Pages 1 and 4 are included for complete double-sided page. Chapter 7 Page 3,8. Modified wording that precluded string data in bridges. Pages 4 and 7 included for complete double-sided pages. Chapter 8 Page 8. New code - HU - added to table 8.1. Page 7 included for complete double-sided page. Chapter 9 Pages 9-12. Added description of Remote Display. Chapter 10 Entire reprint. Added section describing OASIS-CC recorded telemetry file formats for previous and new version of OASIS-CC. Chapter 12 Entire reprint. Removed discussion of task types - all task types are external Appendix A Entire reprint. Spectrometer application is updated to demo CEV, UED and raw commands (binary and ASCII). A bug in the Spectro_saver procedure was fixed wherein ASCII command tables were not committed. OASIS-CC CSTOL Reference Manual (these updates should replace sections in the 'V02.05.08 and subsequent versions of June, 1993') New Title Pages New Contents Chapter 2 Entire reprint. Changed Real number description to reflect that they are now double precision, added previously missing "H" radix, added new special variables and reorganized their description based on the ownership of the variables. Chapter 4 Pages 3,4. Updated SEND reference to include ASCII. Included POLL and STOP POLLING to Communications directives. Chapter 5 Page 10-14. Added to and clarified the available WAIT statements. Page 9 included for complete double-sided copies. Chapter 7 Page 6-10. Embellished the discussion of the available forms of the WAIT statement, as well as the new special variables that can affect the execution of CSTOL procedures. Page 5 included for complete double-sided pages. Chapter 9 Entire reprint. Added new verbs to the available verb list, present raw ASCII command along with the raw binary. Added reference to new Appendix C for adding command verbs to the list. Chapter 10 Entire reprint. Changes were made to the following directives to clarify previous descriptions: INSERT,REPORT,UPDATE,DELETE, REPORT,RECORD,POLL,STOP POLLING. Changes were made to the following directives to include new features available with V02.05.09: CLEAR,DISPLAY,RUN,SEND, SHOW,WAIT,WAIT FOR,FLUSH. Appendix A Pages 3,4. Clarify which directives can be passed from the User-CLP to Sub-CLPs. Appendix B Page 2. Removed indication that EU * EU is legal. Page 1 provided for complete double-sided page. Appendix C New. Describes how to add or delete command verbs from the CSTOL parser file. OASIS-CC Database Guide (these updates should replace sections in the 'V02.05.08 and subsequent versions of June, 1993') New Title Pages (new contents not needed) Chapter 2 ANALOG_CONVERSIONS Chapter 3 ASCII_COMMAND_MAPS (*) Chapter 4 ASCII_COMMAND_VALUES Chapter 6 COMMANDS Chapter 10 COMMAND_VALUES Chapter 11 COMMAND_VALUE_CONVERSIONS Chapter 13 DISPLAY_DEFINITIONS (*) Chapter 14 DISPLAY_DESCRIPTIONS (*) Chapter 19 LATEST_DATA Chapter 20 LIMITS (*) Chapter 21 LINKS Chapter 30 UTILITY_TASKS Appendix A Data type formats have changed over the course of several releases. (*) Indicates that a clarification was made or a typo corrected. All others contain new info relevant to V020509 OASIS-CC Quick Reference Guide (this should replace the 'V02.05.08 and subsequent versions of June, 1993') Entire reprint. This document has been updated with pagination on a chapter basis. Changes were made to Chapter 7 to reflect that devices on BUS streams act as their command channels elements, and therefore IEEE devices should have a flat hierarchy in element_hierarchies. Procs should be decompiled when not needed was added to Appendix A - Performance Considerations. OASIS-CC Installation Guide New version. 9 Upgrades To The Spectrometer Application -------------------------------------------- Several changes were made to the spectrometer application. A new installation of the spectrometer for V020509 is required to see the changes. Follow the instructions in the OASIS-CC Application Environment Reference Manual. 1) The $$SEND_RAW_BITS command is included and set up to send 24 bits to the spectrometer data generator. 2) The $$SEND_RAW_ASCII command is included and set up to send 80 characters to CSTOL_OUTPUT (the link to send CSTOL to a remote OASIS-CC). 3) The TURN ON HIGH_VOLTAGE and TURN OFF HIGH_VOLTAGE have Command Execution Verification enabled. 4) The HIGH_VOLTAGE STATUS measurement is enabled for Unexpected Event Detection. 5) A correction to the PRE_HVON procedure is included (an END IF was missing). 6) Spectro_saver.prc was fixed to commit 2 tables that had been left. New OASIS-CC Tools area As of V020509, a new directory exists in the OASIS-CC installation used to store useful OASIS-CC tools (procedures, interface resources, etc.). We're starting out by providing an example of a wildcard display. To get this display (and it's associated stuff), setup for your application, and then source $ODIST/common_distrib/get_wildcard.csh and follow the instructions. Appendix A: DATABASE TABLE LAYOUT This Appendix describes the layout changes of the analog_conversions, commands, ascii_command_values, ascii_command_maps, command_values, links, command_value_conversions and latest_data table. COMMANDS **************** The following fields have been added after DO_POSTCHECK DO_CEV This flag indicates if CEV is to be executed for this command NON KEY Protection Class : OASIS_MASTER Data type : BOOLEAN Default value : FALSE CEV_EXTERNAL_ELEMENT External element name of the measurement which value is to be used to verify the execution of the command. NON KEY Protection Class : OASIS_MASTER Data type : NAME_TYPE Default value : CEV_ITEM_NAME Item name of the measurement which value is to be used to verify the execution of the command. NON KEY Protection Class : OASIS_MASTER Data type : NAME_TYPE Default value : CEV_GROUP_NAME Name of the command group to which the command belongs for CEV purpose. The notion of command group is very loose. For example it can be a subsystem. NON KEY Protection Class : OASIS_MASTER Data type : NAME_TYPE Default value : "UNSPECIFIED" CEV_VALUE The value the least significant 32 bits of the measurement named in the fields CEV_EXTERNAL_ELEMENT and CEV_ITEM_NAME should have after the command has executed. This value is taken into account if and only if the CEV_MASK field is nul. NON KEY Protection Class : OASIS_MASTER Data type : INTEGER Default value : CEV_MASK This field defines the bits that should be set in the least significant 32 bits of the measurement named in the CEV_EXTERNAL_ELEMENT and CEV_ITEM_NAME fields after the command has executed. Enter this field in hexadecimal, the following way: 1 is expressed as "00000001", 8 as "00000008", F1 as "000000f1", etc. NON KEY Protection Class : OASIS_MASTER Data type : BIT_STRING(1..32) Default value : CEV_TIMEOUT The maximum amount of time (in seconds), OASIS-CC should wait for the command to verify. NON KEY Protection Class : OASIS_MASTER Data type : DURATION Default value : 0.0 The following field has been modified LENGTH This field presents the numbers of bits in a non-ASCII command. If the command is ASCII and its name is $$SEND_RAW_ASCII, this field presents, if =/ 0, the number of characters of the command. If 0, the length of the command is defined by the string specified in the SEND directive. NON KEY Protection Class : DB_MANAGER Data type : INTEGER 0..MAX_COMMAND_SIZE [NOTE 0 INSTEAD OF 1] Default value : 1 ASCII_COMMAND_VALUES ************ The type of the field MAX_VALUE, MIN_VALUE has been changed from FLOAT to LONG_FLOAT. Note that the type LONG_FLOAT has the following characteristics: -1.797E+308 to +1.797E+308 The maximun length of a substring has been increased from 128 characters to 256 characters (constant MAX_SUBSTRING_SIZE). This affects the fields SUBSTRING_VALUE, SUBSTRING_LENGTH, DEFAULT_SUBSTRING_VALUE, DEFAULT_SUBSTRING_LENGTH, PREVIOUS_SUBSTRING_VALUE and PREVIOUS_SUBSTRING_LENGTH. ASCII_COMMAND_MAPS *********** The maximum length of a substring has been increased from 128 characters to 256 characters (constant MAX_SUBSTRING_SIZE). This affects the fields: SUBSTRING_VALUE and SUBSTRING_LENGTH. COMMAND_VALUES ************** The type of the field MAX_VALUE, MIN_VALUE, DEFAULT_VALUE, PREVIOUS_VALUE and VALUE has been changed from INTEGER to LONG_FLOAT. A new field has been added between VALUE and SAFETY_LEVEL: MAPPING_FORMAT Indicates the output format to use for this subfield NON_KEY Protection class : DB_MANAGER Data type: MAPPING_FORMAT_TYPES Default value: INTEGER The type MAPPING_FORMAT_TYPES can take the following value: INTEGER, IEEE_FLOAT and IEEE_LONG_FLOAT. COMMAND_VALUE_CONVERSIONS *********** The type of the field EU_VALUE, CO, C1, C2, C3 has been changed from FLOAT to LONG_FLOAT. COMMAND_STATE_CONVERSIONS ********** The maximun length of a substring has been increased from 128 characters to 256 characters (constant MAX_SUBSTRING_SIZE). This affects the field SUBSTRING_VALUE. LATEST_DATA ******************* The following field has been added after the DELTA_ENABLED field. UED_ENABLED For numeric items or state items, this field indicates if unexpected event detection is enabled NON KEY Protection Class : ANY_USER Data type : BOOLEAN Default value : FALSE ANALOG_CONVERSIONS *************** The following fields have been added: CONVERSION_TYPE This field indicates the type of the dn to eu conversion. It can take the values of SEGMENTED_3D, UNSEGMENTED_5D or UNSEGMENTED_EXP. NON KEY Protection Class : DB_MANAGER Data type : ANALOG_CONVERSION_TYPE Default value : SEGMENTED_3D C4 NON KEY Protection Class : DB_MANAGER Data type : FLOAT Default value : 0.0 C5 NON KEY Protection Class : DB_MANAGER Data type : FLOAT Default value : 0.0 LINKS ********************************** The size of the DATA_LINE field has been extended to 128 characters. Appendix B: CSTOL CHANGES This appendix details the extensions done to the CSTOL language in this release. WAIT *********************** The WAIT directive has been extended and reads as follows: WAIT suspends a procedure. Suspension types include: - Indefinite suspension of the procedure until a GO statement is entered - Temporary suspension of the procedure for a specified length of time or until an absolute time - Conditional suspension of the procedure until a condition is met - Conditional suspension of the procedure until a condition is met or a specified length of time has expired or a absolute time has been reached Format WAIT WAIT delta time WAIT absolute time WAIT conditional expression [OR FOR delta time] | [OR UNTIL absolute time] Arguments Notes 5. The condition is reevaluated every $$CHECK_INTERVAL 6. A conditional wait returns NO_ERROR in $$ERROR when the condition is met. It returns TIME_OUT in $$ERROR if the delta time has expired or the absolute time has been reached before the condition has been met. WAIT FOR *********************** WAIT FOR is used with Command Execution Verification (CEV) Format WAIT FOR command_group_name WAIT FOR ALL WAIT FOR LAST Arguments command_group_name (identifier) : name of the command group the wait directive applies to. Notes 1. The WAIT FOR command_group_name statement blocks a procedure until the following conditions are met: (1) There are no more commands pending cev for the group command_group_name and; (2) None of the commands from the group that have been sent since the last WAIT FOR command_group_name, the last FLUSH command_group_name (with the same group name), the last WAIT FOR ALL or the last FLUSH ALL have failed verification 2. The WAIT FOR command_group_name statement blocks indefinitively a procedure (i.e., does the equivalent of parameterless WAIT statement) under the following conditions: (1) There are no more commands pending cev for the group command_group_name; and (2) At least one of the commands from the group that have been sent since the last WAIT FORT command_group_name, the last FLUSH command_group_name (with the same group name), the last WAIT FOR ALL or the last FLUSH ALL has failed verification. 3. At the conclusion of a successful or unsuccessful WAIT command_group_name statement, the group command_group_name is reset (i.e., the equivalent of a FLUSH command_group_name is executed). 4. The WAIT FOR ALL statement blocks a procedure until the following conditions are met: (1) There are no more commands pending cev and; (2) None of the commands that have been sent since the last WAIT FOR ALL or the last FLUSH ALL have failed verification. 5. The WAIT FOR ALL statement will block indefinitively a procedure (i.e., does the equivalent of parameterless WAIT statement) under the following conditions: (1) There are no more commands pending cev; and (2) At least one of the commands that have been sent since the last WAIT ALL command_group_name or the last FLUSH ALL has failed verification. 6. At the conclusion of a successful or unsuccessful WAIT FOR ALL statement, all the cev states are reset (i.e., the equivalent of a FLUSH ALL is executed). 7. The WAIT FOR LAST statement blocks a procedure until the last command sent from the clp which is executing the wait statement has verified. If the command has already verified before the statement is executed, the procedure is not blocked. If the command fails the verification (or has failed the verification before the statement is executed) the procedure is indefinitively blocked (i.e., the equivalent of a parameterless WAIT statement is executed). 8. A command_group_name cannot be named ALL or LAST. SHOW ************************ The SHOW directive has been extended as follows: Format SHOW PENDING CEV Arguments None Notes 1. SHOW PENDING CEV outputs to the events log the following information: (1) The number of commands pending CEV and having failed CEV; (2) For each command group, the number of commands pending CEV and having failed CEV in each group; (3) The name of the commands that are pending CEV and the amount of time left before a failure is declared. For example: 93/275-13:37:27 LP_U (CRN_308_A) show pending cev 93/275-13:37:27 CI 4 commands are pending, 0 commands have failed system wide 93/275-13:37:27 CI 3 commands are pending, 0 commands have failed in group AA 93/275-13:37:27 CI 1 commands are pending, 0 commands have failed in group BB 93/275-13:37:27 CI Command GRATING, SET_POSITION_2 has 20.0570 seconds before timeout 93/275-13:37:27 CI Command GRATING, SET_POSITION_3 has 3.2710 seconds before timeout 93/275-13:37:28 CI Command GRATING, SET_POSITION_4 has 15.4510 seconds before timeout 93/275-13:37:28 CI Command GRATING, SET_POSITION_5 has 0.6880 seconds before timeout FLUSH ************************************ This directive resets the CEV subsystem. Format FLUSH command_group_name FLUSH ALL Arguments command_group_name (identifier) : name of the command group to be re-initialized Notes 1. The FLUSH command_group_name clears the counters of pending commands and of commands that have failed for the command group command_group_name. All commands from that command group that are pending are removed from the pending verification queue. 2. The FLUSH ALL clears the counters of pending commands and of commands that have failed for all commands' groups. All commands that are pending are removed from the pending verification queue. SEND ************************************ SEND sends a command message or a command expressed as bit pattern or an ASCII string. Format SEND MESSAGE SEND bit-pattern-command TO external-element-name SEND quoted-character-string TO external-element-name SEND local-variable-name TO external-element-name SEND global-variable-name TO external-element-name Arguments bit-pattern-command (H#hex-integer-constant): The hexadecimal representation of the command. quoted-character-string: An alphanumeric text preceded and terminated by quotes local-variable-name: The name of a local variable (i.e., a $ variable) containing a character string global-variable-name: The name of a global variable (i.e., a latest_data table measurement) containing a character string. external-element-name (identifier): The external element recieving the command. Notes: 1. Single quote characters (i.e., ') in a character string are replaced by double quote characters (i.e., ") when the character string is send. 2. The global variable must be of the data_class character_string. 3. Local variable must be of type string. DISPLAY ************************************ see paragraph 4.13 above. Appendix C: 1553 RT USER'S GUIDE 1553 LOW RATE SCIENCE PROTOCOL REMOTE TERMINAL USER'S GUIDE This appendix provides a short user's guide for the 1553 low rate science protocol (EOS/am) remote terminal support. The user's guide for the Bus Controller side was published in the V02.05.06 release notes (available in the $ODIST/release_notes directory) 1 - General Notes The implementation allows the transfer to the bus controller of "routed" data or of data read from a file over a 1553 bus under the low rate science protocol defined in the EOS GIIS document. The implementation does not interpret any of the mode code that can be sent by the bus controller (except of course for "transmit vector word" which is needed to initiate a transfer). The implementation is based on the use of an Engineering Design team (EDT) S53B1 interface board and its associated driver. 2 - Limitations The transfer of blocks smaller that 8192 bits has been successfuly tested. The transfer between 2 SparcStations running SunOs 4.1.3 of blocks larger than 8192 bits has been shown to fail about 1% of the time. This is because under SunOs it is impossible to insure that the remote terminal has reloaded the sub addresses 10 to 25 within 20 milliseconds of the bus controller having read these subaddresses. The SOLARIS version of OASIS-CC does not currently support transfer of blocks larger than 8192 bits. 3 - Database Set Up The following paragraphs give an overview of the specific database set up for the protocol. 3 - 1 Streams Table The primary stream provides the mechanism by which the 1553 remote terminal task can be started. This is controlled by the user via the CSTOL switch on/of directive. STREAM_NAME => name of the stream DESCRIPTION => PROCESSOR => EXTCOMM_SUBSYSTEM LINK_NAME => pointer to the links record DIRECTION => FORWARD_STREAM PROTOCOL => FIFTEEN_53_LR_RT STREAM_TYPE => PRIMARY PARENT => not used STREAM_IS_ON => system used TIME_OUT => not used RECORD_IS_ON => not used (forward stream) RECORD_FILE_NAME => not used (forward stream) ASSOCIATED_FORWARD_NAME => not used (forward stream) RETRIEVE_IS_ON => not used (forward stream) FRAME_LENGTH => maximum size of the packets that will be routed to the task or, if the task reads the data from a simulation file, size of each transfer SECONDARY_OFFSET => not used ID_VALUE => not used INCREMENTAL => not used SYNC_PATTERN_LENGTH => not used SYNC_PATTERN => not used EXTERNAL_ELEMENT => currently not used FRAME_COUNT_NAME => currently not used SYNC_ERR_COUNT_NAME => currently not used 3 - 2 Links Table LINK_NAME => as defined in the primary stream table DATA_LINE => should contain the driver name and the rt address separated by a blank. Example: /dev/s53bi0 10 EXTERNAL_ELEMENT => not used BLOCK_COUNT_NAME => not used CRC_ERROR_COUNT_NAME => not used TEST_COUNT_NAME => not used RETRY_COUNT_NAME => not used 3 -3 Latest_Data table EXTERNAL_ELEMENT => Name of the stream ITEM_NAME => DEBUG_LEVEL DATA_CLASS => NUMERIC EU_UNITS => DN DN_LOW => 0, 1 or 2. If 0 no debug messages are printed. Default is 0. EXTERNAL_ELEMENT => Name of the stream ITEM_NAME => TEST_SUBADRESS DATA_CLASS => NUMERIC EU_UNITS => DN DN_LOW => 10 to 25. Indicates the subaddress to test for BC read if the tranfer size is greater than 8192 bits before reloading the subaddresses. Default is 25. EXTERNAL_ELEMENT => Name of the stream ITEM_NAME => FILENAME DATA_CLASS => CHARACTER_STRING EU_UNITS => DN CHAR_STRING => name of the file (including path) to transfer data from. NOTE THAT IF THIS RECORD EXISTS, OASIS-CC ASSUMES THAT THE TASK WILL NOT TRANSFER "ROUTED" DATA. EXTERNAL_ELEMENT => Name of the stream ITEM_NAME => FILE_SAMPLE_RATE DATA_CLASS => NUMERIC EU_UNITS => DN EU_VALUE => number of seconds between two successive reads of the file. Default value is 0.0 Appendix D: THRUPUT MEASUREMENTS THRUPUT MEASUREMENTS OASIS-CC thruput was measured under the following conditions: Computer : Sparcstation 2, 32 Mbyte of main memory OS : SOLARIS 2.2 OASIS-CC : - Release of v02.05.09. Compiled with run-time checks ON - Application set up to decompose 128 measurements per packet. Measurements are converted to engineering unit using the analog conversion table and are limit checked. - Protocol used is Ip - OASIS-CC verifies the sync pattern of each packet Simulator: - Packet size set to 128 bytes - Running on a remote workstation In the measured % of cpu, three numbers are given. The first one is computed using the ps command. The second and the third one are the %cpu for user and idle as reported by the vmstat command. measured measured # measurements # measurements Limits measured packet bit decomposed changing status % of cpu rate rate per second per second 16/s 16kbps 0 n/a n/a << 1 16/s 16kbps 2048 0 n/a 16,16,86 16/s 16kbps 2048 1984 off 48,44,51 16/s 16kbps 2048 1984 on 52,51,46 24/s 24kbps 0 n/a n/a << 1 24/s 24kbps 3072 0 n/a 24,24,76 24/s 24kbps 3072 240 on 30,30,69 24/s 24kbps 3072 480 on 34,34,65 24/s 24kbps 3072 1200 on 48,45,51 32/s 32kbps 0 n/a n/a << 1 32/s 32kbps 4096 0 n/a 36,35,63 32/s 32kbps 4096 320 on 40,40,59 32/s 32kbps 4096 640 on 49,46,52 For all measurement, the primary stream was set up with a frame_length of 4096 and a time_out of 0.05. Computer : Sparcstation 2, 32 Mbyte of main memory OS : SunOs 4.1.3 OASIS-CC : - Release of v02.05.09. Compiled with run-time checks ON - Application set up to decompose 128 measurements per packet. Measurements are converted to engineering unit using the analog conversion table and are limit checked. - Protocol used is Ip - OASIS-CC verifies the sync pattern of each packet Simulator: - Packet size set to 128 bytes - Running on a remote workstation In the measured % of cpu, three numbers are given. The first one is computed using the ps command. The second and the third one are the %cpu for user and idle as reported by the vmstat command. measured measured # measurements # measurements Limits measured packet bit decomposed changing status % of cpu rate rate per second per second 16/s 16kbps 0 n/a n/a << 1 16/s 16kbps 2048 0 n/a 16,17,82 16/s 16kbps 2048 1984 off 47,43,54 16/s 16kbps 2048 1984 on 53,53,46 24/s 24kbps 0 n/a n/a << 1 24/s 24kbps 3072 0 n/a 28,30,70 24/s 24kbps 3072 240 on 30,30,68 24/s 24kbps 3072 480 on 38,37,60 24/s 24kbps 3072 1200 on 48,48,51 32/s 32kbps 0 n/a n/a << 1 32/s 32kbps 4096 0 n/a 38,38,61 32/s 32kbps 4096 320 on 45,41,56 32/s 32kbps 4096 640 on 49,51,49 For all measurement, the primary stream was set up with a frame_length of 4096 and a time_out of 0.05. Appendix E: IEEE-448 USER'S GUIDE IEEE-488 USER'S GUIDE This Appendix provides a short user's guide for the current IEEE-488 implementation. After review we plan to add this note to the generic communication guide. It is an update of the user's guide that was published in the v02.05.06 release notes. Updated portion are identified by [NEW]. 1 - General Notes 1 - 1 General description This implementation allows a user to (1) Execute IEEE-488 control commands; (2) Send device specific commands to IEEE-488 Listener devices; (3) Get data from IEEE-488 talker devices at a user-defined frequency; (4) Get and decompose IEEE-488 devices status byte; and (5) Wait for the SRQ line to be asserted and get and decompose the status byte of the devices that have requested service. The implementation uses a National Instrument IEEE-488 interface and its associated SunOS 4.1 or SOLARIS 2.2 driver. ************************************************************************** * Note that the serial polling capability only works in OASIS-CC if the * * National Instruments driver is installed with the automatic serial * * polling disabled. Refer to the National Instruments NI-488M driver * * installation guide documentation. * ************************************************************************** Note that accessing (synchronously or asynchronously) the status byte of a device that is non-existing or is not powered causes a bus error: When this happens OASIS-CC tries to re configure the bus by pulsing the IFC line for 100 microseconds. For some "non-standard" GPIB devices this is not long enough. In that case the user can manually re configure the bus using the INITIALIZE stream_name CSTOL statement. This OASIS-CC implementation for IEEE-488 differs in many ways from the one used in the VMS version of OASIS-CC (and described in the current version of the System Manager's Guide). The bus_decompositions table has been removed. Decomposition of the IEEE-488 data are now defined by decomposition table. The ieee_device_descriptions table has been redesigned. The CSTOL make statement has also been redesigned. The basic application set up matches more closely a regular application set up: the bus to which the IEEE-488 devices are attached is mapped to an OASIS-CC primary stream and each devices output is mapped to a secondary stream that can be decomposed and/or routed using the information contained in the decomposition table. The implementation has been tested with several IEEE-488 devices, including a Keithly Model 195a Digital Multimeter, a Keithly Model 775a Programmable Counter/Timer and a Klinger CC-1 Programmable Stepper Motor Controller. 1 - 2 Setting up the Ib device driver [NEW] For OASIS-CC to work properly it needs to have read/write privilege to the /dev/devx files used by the Ib driver. 1 - 3 Using ibconf to configure the device driver [NEW] When using OASIS-CC with a single interface board and if this board is /dev/gpib0 you can configure your installation via the IEEE_DEVICE_DESCRIPTIONS table or by using the ibconf utility. In all the other cases (i.e., more than one board is used or if only one board is used it is not /dev/gipb0) you cannot use the IEEE_DEVICE_DESCRIPTIONS table and you need to use the ibconf utility as described in the NI-448M manuals. 2 - Database Set Up The following paragraphs give an overview of the specific database set up for the IEEE-488 implementation. 2 - 1 Streams Table 2 - 1 - 1 Primary Stream : one record per IEEE-4888 bus The primary stream provides the mechanism by which a IEEE-488 process can be started. This is controlled by the user via the CSTOL switch on/off or retrieve on/off directives. The primary stream can recorded via the record on/off CSTOL directives. STREAM_NAME => name of the stream DESCRIPTION => PROCESSOR => BUS_SUBSYSTEM LINK_NAME => pointer to the links record DIRECTION => not used PROTOCOL => IEEE STREAM_TYPE => PRIMARY PARENT => not used STREAM_IS_ON => system used TIME_OUT => indicates the maximum rate at which the polling is to be done RECORD_IS_ON => system used RECORD_FILE_NAME => system used ASSOCIATED_FORWARD_NAME => not used RETRIEVE_IS_ON => system used FRAME_LENGTH => maximum size of the output of all the talker devices SECONDARY_OFFSET => not used ID_VALUE => not used INCREMENTAL => not used SYNC_PATTERN_LENGTH => not used SYNC_PATTERN => not used EXTERNAL_ELEMENT => currently not used FRAME_COUNT_NAME => currently not used SYNC_ERR_COUNT_NAME => currently not used 2 - 1 - 2 Secondary Stream : One record per talker device on an IEEE-488 bus Each device output stream is mapped to a secondary stream. So one record is needed per device that will be read and whose output needs to be decomposed or routed. The decomposition of each secondary stream is defined by the decomposition table and is controlled by the user via the switch on/off CSTOL directives. Routing is controlled by the route/stop routing CSTOL directives. STREAM_NAME => name that will be used to identify this IEEE-488 device DESCRIPTION => PROCESSOR => BUS_SUBSYSTEM LINK_NAME => name of the substream that is used to define the decomposition of the status byte DIRECTION => not used PROTOCOL => IEEE STREAM_TYPE => SECONDARY PARENT => name of the primary stream STREAM_IS_ON => system used TIME_OUT => not used RECORD_IS_ON => not used RECORD_FILE_NAME => not used ASSOCIATED_FORWARD_NAME => not used RETRIEVE_IS_ON => not used FRAME_LENGTH => greater than the length of the data stream output by the device SECONDARY_OFFSET => as needed ID_VALUE => not used INCREMENTAL => not used SYNC_PATTERN_LENGTH => not used SYNC_PATTERN => not used EXTERNAL_ELEMENT => not used FRAME_COUNT_NAME => not used SYNC_ERR_COUNT_NAME => not used 2 - 1 - 3 Stream used to define the decomposition of the status byte STREAM_NAME => name that will be used to define the decomposition of the status byte DESCRIPTION => PROCESSOR => BUS_SUBSYSTEM (not checked currently) LINK_NAME => not used DIRECTION => not used PROTOCOL => IEEE (not checked currently) STREAM_TYPE => SECONDARY or SUBSTREAM (not checked currently) PARENT => not used STREAM_IS_ON => not used TIME_OUT => not used RECORD_IS_ON => not used RECORD_FILE_NAME => not used ASSOCIATED_FORWARD_NAME => not used RETRIEVE_IS_ON => not used FRAME_LENGTH => not used SECONDARY_OFFSET => not used ID_VALUE => not used INCREMENTAL => not used SYNC_PATTERN_LENGTH => not used SYNC_PATTERN => not used EXTERNAL_ELEMENT => not used FRAME_COUNT_NAME => not used SYNC_ERR_COUNT_NAME => not used Note that the status byte stream is always on and that the status byte is never recorded. 2 - 2 Links Table : one record per primary IEEE-488 stream LINK_NAME => as defined in the primary stream table DATA_LINE => Should contain the driver name. Example: /dev/gpib0 EXTERNAL_ELEMENT => not used BLOCK_COUNT_NAME => not used CRC_ERROR_COUNT_NAME => not used TEST_COUNT_NAME => not used RETRY_COUNT_NAME => not used 2 - 3 Element Characteristics Table One record is needed per IEEE-488 device attached to an IEEE-488 bus. NAME => name that will be used to identify this IEEE-488 device DESCRIPTION => LATENCY => not used BANDWIDTH => not used COMMAND_CODING => as needed by the device command set up STREAM_NAME => name of the primary stream All the other fields are "as needed by the device command set up". 2 - 4 IEEE Device Descriptions Table This table can be used to describe the devices that are on the bus if and only if only one board is used and this board is /dev/gpib0 [NEW]. In all cases ibconf can be ÿûused to describe the devices. However if ibconf is used, this table should be empty. [NEW] One record is needed per IEEE-488 device attached to the bus. EXTERNAL_ELEMENT => name that will be used to identify this IEEE-488 device PRIMARY_ADDRESS => primary address of the device SECONDARY_ADDRESS => secondary address of the device WRITE_TERMINATION_MODE => as defined for the device READ_TERMINATION_MODE => as defined for the device MATCHING_CHARACTER => as defined for the device TIME_OUT => maximum amount of time OASIS-CC should wait for the device to answer a sample request. Note: This table is used to override the contents of the device special files defined using the ibconf software supplied with the National Instrument gpib board and driver. 3 - Other Set Up The decomposition table is set up the regular way. The command-related tables are set up the regular way. 4 - CSTOL Directives 4 - 1 Sampling and Polling Directive (see the CSTOL reference manual) SAMPLE device_list EVERY sample rate SAMPLE device_list STOP SAMPLING device_list STOP SAMPLING ON stream_list POLL BUS stream_list POLL DEVICE device_list STOP POLLING BUS stream_list 4 - 2 Bus Control (see the CSTOL reference manual) To have devices go to remote mode: MAKE DEVICE device_list BE REMOTE MAKE ALL DEVICES ON stream_list BE REMOTE To have devices go to local mode: MAKE DEVICE device_list BE LOCAL To place devices in local lockout state: MAKE DEVICE device_list BE LOCAL_LOCK MAKE ALL DEVICES ON stream_list be LOCAL_LOCK To trigger devices: MAKE DEVICE device_list DO TRIGGER To reset devices: MAKE DEVICE device_list BE RESET MAKE ALL DEVICES ON stream_list BE RESET To initialize a bus: INITIALIZE stream_name Note: INITIALIZE asserts the IFC line for a few milliseconds. This should be enough to clear GPIB bus error, even with non-standard GIPB devices. Appendix F: PARSER UPDATE COOK BOOK HOW TO ADD/DELETE COMMAND VERB FROM THE PARSER It is possible in OASIS-CC to add or delete verbs in the command sub-language. This capability should be used with extreme care and changes should be coordinated between members of the same project to make sure that no incompatibilities are created. To update the command sub-language verb list, two steps are necessary: (1) Edit parser.dat file. This file (in $OASIS_PARSER) contains the ascii representation of the parsing rules. (2) Convert the ascii file into a binary file understandable by OASIS-CC by entering $ODIST/bin/convert_table. This creates in $OASIS_PARSER a file called parser_int.dat. This is the file from which OASIS-CC loads the language rules at run-time. Edition of the parser.dat file should be done with great care: (1) Find the comment "THIS PORTION OF PARSER.DAT FILE CAN BE MODIFIED" ; ; THIS PORTION OF PARSER.DAT FILE CAN BE MODIFIED TO ADD OR REMOVE CMD VERBS STATE TRAN 'NOW' ,CMD_HOLD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'HOLD' ,CMD_NAME_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'ENABLE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'CHANGE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'CLOSE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'DISABLE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'HALT' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'MOVE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'OPEN' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'SET' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'TOGGLE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'TURN' ,TURN_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'BOOT' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'SELECT' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'DUMP' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'IGNORE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'USE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'PASS' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'DRIVE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'FORCE' ,TURN_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'FLYBACK' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !RESET ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !STEP ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !TEST ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !PERFORM ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !SLEW ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND ; END OF THE PORTION OF PARSER.DAT THAT CAN BE MODIFIED TO ADD OR REMOVE ; CMD VERBS (2) Remove the lines that correspond to the verbs you want to remove and/or add the lines that correspond to the verbs you want to add. For example: ; ; THIS PORTION OF PARSER.DAT FILE CAN BE MODIFIED TO ADD OR REMOVE CMD VERBS STATE TRAN 'NOW' ,CMD_HOLD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'HOLD' ,CMD_NAME_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'ENABLE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'CHANGE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'CLOSE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'DISABLE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'HALT' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'MOVE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'OPEN' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'SET' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'TOGGLE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'TURN' ,TURN_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'BOOT' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'SELECT' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'DUMP' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'IGNORE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'USE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'PASS' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'DRIVE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'FORCE' ,TURN_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'FLYBACK' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !RESET ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !STEP ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !TEST ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !PERFORM ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN !SLEW ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND ; Additional sub language verbs added 10/93 per crn 330 TRAN 'ARM' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'DISARM' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'FIRE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'INITIATE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'ACTIVATE' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND TRAN 'GET' ,NORMAL_CMD_STATE ,EXTENDED_DIRECTIVE_TOKEN,COMMAND ; END OF THE PORTION OF PARSER.DAT THAT CAN BE MODIFIED TO ADD OR REMOVE ; CMD VERBS Appendix G: RAW DATA FORMAT (PREVIOUS RELEASES) RAW DATA FILE FORMAT (for V02.05.04 to V02.05.08) The recorded data file format for OASIS-CC release 04 to 08 can be described as follows (ALL PROTOCOL EXCEPT IEEE_488): V02.05.04 4 bytes julian day number integer 4 bytes tenth of mill. sec. integer 4 bytes filler #1 integer frame_length/8 bytes data application dependent V02.05.05 to V02.05.08 4 bytes julian day number integer 4 bytes tenth of mill. sec. integer 4 bytes filler #1 n/a frame_length/8 bytes data application dependent 12 bytes filler #2 n/a The recorded data file format for OASIS-CC can be described as follows (IEEE_488 protocol): V02.05.04 4 bytes julian day number integer 4 bytes tenth of mill. sec. integer 4 bytes filler #1 integer 16 bytes device name ascii characters frame_length/8 bytes data application dependent V02.05.05 to V02.05.08 4 bytes julian day number integer 4 bytes tenth of mill. sec. integer 4 bytes filler #1 n/a 16 bytes device name ascii characters 4 bytes filler #3 n/a frame_length/8 bytes data application dependent 12 bytes filler #2 n/a Notes: (1) Julian day number: number of days since Jan 1, 4713 B.C, 12:00 noon (2) Tenth of mill. sec. SEEMS to be from Midnight GMT. (3) frame_length : value of the frame_length entry for the PRIMARY stream in the streams table. (4) The time code corresponds to the system time when the record was recorded (basically the time of the acquisition of the last byte in the record). Appendix H: RAW DATA FORMAT (V02.05.09 AND UP) OASIS-CC RAW DATA RECORDING FORMAT This note describes the format of the recorded raw data file that will be available starting v020509. It also describes how and when the data are recorded by OASIS-CC (ref: crn 350) 1 - RAW DATA FILE FORMAT DESCRIPTION A raw data file is made of one (1) Header Record, followed by many Data Records. All the records have the same length. The purpose of the Header Record is to provide information that can be used by offline programs developed to process raw files. Header Record Format (first record) Field Position Data Type Contents Example 1 Bytes 1..4 Integer Year of file creation 1993 2 Bytes 5..8 Integer Month of file creation 11 3 Bytes 9..12 Integer Day of file creation 28 4 Bytes 13..16 Integer Tenth of milliseconds 83000000 of file creation 5 Bytes 17..20 Integer Format version number 1 6 Bytes 21..24 Integer Record length (RL) in bytes 1034 7 Bytes 25..RL n/a n/a Data Record Format (Non IEEE-488 protocol) Field Position Data Type Contents Example 1 Bytes 1..4 Integer Year 1993 2 Bytes 5..8 Integer Month 11 3 Bytes 9..12 Integer Day 28 4 Bytes 13..16 Integer Tenth of milliseconds 83000000 5 Bytes 17..20 Integer Quality code 0 good = 0 bad /=0 6 Bytes 21..24 Integer Valid portion of the data 120 field (in number of bytes) 7 Bytes 25..RL Data field Data Record Format (IEEE-488 protocol) Field Position Data Type Contents Example 1 Bytes 1..4 Integer Year 1993 2 Bytes 5..8 Integer Month 11 3 Bytes 9..12 Integer Day 28 4 Bytes 13..16 Integer Tenth of milliseconds 83000000 5 Bytes 17..20 Integer Quality code 0 good = 0 bad /=0 6 Bytes 21..24 Integer Valid portion of the data 120 field (in number of bytes) 7 Bytes 25..40 ASCII Device name DMM_195 8 Bytes 41..RL Data field NOTES (1) Time field (fields 1 to 4) in Header Record. These fields contain the date and time at which the file was created. This is taken from the system time. (2) Version number (field 5 of the Header Record). This field is currently set to 1. (3) Record length field (field 6 in Header Record). This field contains the length in bytes of each record, including the Header Record. (4) Time field (fields 1 to 4) in each Data Record. These fields contain the data and time at which the record was written to the file. This is basically the time with the last valid byte of the record. This is taken from the system time. (5) Quality field (field 5 in Data Record). This field is set to zero (0) if no I/O errors were reported by the operating system while acquiring the data in the record. This field is set to a value non equal to zero if a I/O error was reported by the operating system while acquiring the data in the record (see next paragraph for more detail). (6) Valid potion of the data field (field 6 in Data Record). This field contains the number of bytes that are valid in the data field. Depending on the protocol the record may not be always filled with data (see next paragraph for more detail). (7) The size of the data field is defined by the frame length value in the streams table record defining the primary stream. 2 - OASIS-CC RECORDING STRATEGY The way OASIS-CC records data depends on the characteristics of the protocol used to acquire the data. If the data come as a stream of bytes (i.e., when one OASIS-CC read does not return a message - for example a packet or a TDM frame - within its boundary), the data bytes are stuffed in a recording buffer as they come and the buffer is written to disk when it is full. This means that one Data Record can contain more than one message and that a message can span more than one Data Record. This mechanism applies to the IP protocol and the ASYNC_CHAR protocol. Otherwise (i.e., when the protocol is a message oriented protocol, where one OASIS-CC read returns one message), data is recorded one message at a time (i.e, there is one message per Data Record). In this case it is unlikely that the Data Record will be always filled. This mechanism applies to the FIFTEEN_53_LRS protocol, the S11W_1 protocol and the IEEE protocol. With the IP protocol and the ASYNC_CHAR protocol (i.e., with a stream oriented protocol), data is passed to OASIS-CC with no error being reported by the operating system. Therefore, in this case the Quality field is always set to 0. All the Data Records should be full, except of course the last one. With the other protocols (i.e., with a message oriented protocol), I/O errors can be reported while a message is read. In this case the quality flag is set to a number different from 0 and the field 6 contains what OASIS-CC thinks is the amount of data that was read before the I/O error occured. If this is 0 bytes OASIS-CC does not record the data. Appendix I: OASIS-CC PROCESSING OF "ERRONEOUS" DATA OASIS-CC processing of "erroneous" data This note describes when and how OASIS-CC processes (i.e., applies the decomposition algorithm and/or route data) incoming data under error conditions. The first point is that none of the protocols handled by OASIS specify any application level data check (such as checksum or CRC). Therefore OASIS assumes that the data is Ok unless (1) an I/O error is reported by the operating system while a read is in progress or (2) OASIS-CC loses sync. The former case only applies to messages oriented protocols (FIFTEEN_53_LRS, S11W_1 and IEEE) where one OASIS-CC read yields one message. The latter case applies only to stream oriented protocols (IP and ASYNC_CHAR) where one OASIS-CC reads does not yield data in a message boundary (such as a packet or a TDM frame). 1 - Message Oriented Protocols 1 - 1 FIFTEEN_53_LRS. OASIS-CC reads up to 18 subadresses in one shot and the driver reports I/O errors at the subaddress level. Under the assumption that most of the data may be correct, when an error is reported, OASIS-CC flags the data has being of marginal quality and processes the data. 1 - 2 IEEE. Errors are reported by the operating system driver at the individual read level. Usually, this is a timeout error. OASIS-CC does not attempt to process the available data (note that data is recorded anyway). 1 - 3 S11W_1. This similar to the IEEE protocol for the same reasons. 2 - Stream Oriented Protocols Both the IP and the ASYNC_CHAR protocol work the same way. 2 - 1 If the primary stream is said to be always "in sync" (i.e., when the sync_pattern_length is equal to 1 in the streams table record that defines the primary stream), there are no error possible. Therefore OASIS-CC always processes the data. 2 -2 If the primary stream is said not to be "in sync", OASIS-CC processes data when and only when: (a) The beginning (i.e. the sync pattern) of a TDM or of a packet has been found. (b) The beginning of the next TDM frame or of the next packet (i.e., the next sync pattern) is found just after the current TDM frame or the current packet. Basically OASIS-CC processes data when it has synced on the data, which requires two consecutive sync patterns found at the right place. If these conditions are not met OASIS-CC does not process any data and continue to search for a sync pattern. This search is always forward, OASIS-CC never backtrack (note that data is recorded anyway). Appendix J: SYNC PATTERN, BLOCK ID, ETC... The way users have to express bit pattern in the OASIS-CC database is not obvious. In fact it may appear very strange. Bit patterns are specified in the following database tables: Table name Field name COMMANDS FIXED_PATTERN CEV_MASK COMMAND_MESSAGES HEADER_PATTERN TRAILER_PATTERN DECOMPOSITION BLOCK_ID_VALUE STREAMS ID_VALUE SYNC_PATTERN These fields are expressed in hexadecimal. The first hexadecinal character represents the most significant four bits of the first byte of the pattern, the second hexadecimal represents the least significant four bits of the first byte of the pattern, and so on. In the SYNC_PATTERN field, in each bytes the bit are also reversed (A future release of OASIS-CC will allow the user to express the SYNC_PATTERN correctly. ref: CRN 362) For example for the CEV_MASK field (a 32-bit wide mask) 1 is expressed as "00000001", 8 as "00000008" , F1 as "000000f1". For example for the SYNC_PATTERN field, "FAF320" is expressed as "5FCF04" Appendix K: SOLARIS VERSION STATUS V02.05.09 is the first release of OASIS-CC compatible with the SOLARIS 2.2 operating system. The intent of this note is to give the users some information about the current state of OASIS-CC under this new operating system. 1 - Some SOLARIS notes The version of SOLARIS we are currently running at LASP is 2.2. We do not yet know which SOLARIS patches have been installed. As there are numerous existing patches to SOLARIS 2.2, it is quite possible that what we are reporting has already been fixed by SunSoft. If this is the case we will update this note. We are also running X11R5 and Motif 1.2, both from BlueStone. The Ada compiler we are using is a new version of the SunAda compiler (release 2.0). The only system optimization we have done was to update the kernel maxusers parameter to 64. The first impression is not too good. The system takes a long time to get back to the prompt after an incorrect password has been typed. Doing xinit also takes a long time. To test OASIS thruput we are using a data simulator that can be commanded to output data at a known rate. This program is written in Ada. Because of overhead in its Ada code the data simulator outputs data at a lower rate than requested. The difference between the SunOs 4.1 and the SOLARIS versions is striking (see table 1). Is this due to SOLARIS or to SunAda 2.0? requested rate measured rate measured rate SunOs 4.1 (1) SOLARIS 2.2 (2) 19 kbps 16.6 kbps 14.4 kbps 29 kbps 24.4 kbps 19.0 kbps (1) as measured on a SparcStation 2 and a Sparc IPC (2) as measured on a SparcStation 2 Table 1: measured data rate vs requested rate using the simulator program On the other hand, the RT (realtime) scheduling class which is available with SOLARIS is a huge improvement over SunOs 4.1 and should be always used when running OASIS-CC. 2 - OASIS V02.05.09 status Both V02.05.09 versions of OASIS-CC provide the same capabilities except for what is listed below. Their performances are about the same. 2 - 1 S11W support This support is not currently available with the SOLARIS version. We can make the system crash with small test programs. The culprit may be the asynchronous io code (i.e., aiord() and aiwait() in aiolib) or the EDT driver (EDT is re-writing the S11W driver for SOLARIS). 2 - 2 1553 EOS am low rate science protocol, remote terminal support Transfering data block shorter than 8192 bits works fine. Transfering data blocks larger than 8192 bits does not work: the system gets stuck and has to be rebooted the hard way (i.e., using the power switch as even L1 A does not work). The culprit seems to the select() code, which is used (in a polling mode) to sense if the bus controller has read the remote terminal subaddresses before reloading them. 2 - 3 RS232 support There is big difference of thruput between the SunOs 4.1 version and the SOLARIS 2.2 version when acquiring data using an RS232 connection. In both versions the amount of cpu used by OASIS-CC is about the same. But the system itself (as reported by vmstat) uses a lot more of cpu under SOLARIS than under SunOs 4.1. The difference is so big that it is not currently possible to recommend the use of the RS232 support with the SOLARIS version of OASIS-CC. We also noted that running OASIS-CC under the RT scheduling class did not solve the "sync loss" problem, contrary to what we were expecting. In fact "sync loss" messages seem more common in the SOLARIS version. The RS232 code is different in the two OASIS-CC versions. The SunOs version used the BSD compatibility module (ttcompat()) to set up the transmission port. The SOLARIS version used termios(), as we were unable to have ttcompat() work correctly. However this should be merely a cosmetic change. Table 2 gives the performances measured with the RS232 support code at only 8kbps (as we were unable to run at 16kbps using the SOLARIS version). measured OASIS-CC cpu usage vmstat inferred from ps user sys idle SunOs 4.1.3 8% 9% 2% 89% SOLARIS 2.2 10% 10% 25% 65% Table 2: % of cpu, with RS232 input at 8kps, 1024 measurements extracted per second.