************************************************************************ Media Pro 4000 Brief April 12, 1999 File: CUE_ACCESS_TO_STATUS_BR041200.TXT Module: ICM4020, IMC4010, IMC4020, etc. Title: CUE STATEMENT ACCESS TO STATUS ************************************************************************ c2000 Anitech Systems Incorporated, 25021 Anza Drive, Valencia, CA 91355 Note, this brief replaces all the following, which are obsolete: CUE_ACCESS_TO_STATUS_BR032699.TXT CUE_ACCESS_TO_STATUS_BR100199.TXT CUE_ACCESS_TO_STATUS_BR101299.TXT This brief applies only to ICM firmware from 3220119U.COD. To have support for the LOAD/FROM/STATUS/BYTE form, use MP4000 Software version 1.9.1.8 or newer. MEDIA PRO 4000 STATUS In response to customer requests, we have added a means for cue statements to get status information from modules in the system. As time permits, the capability is augmented, and this document is updated and reissued. It explains the operation of the LOAD/WITH/STATUS/BYTE, LOAD/FROM/STATUS/BYTE, and UNLOAD statements. This brief also gives the status available from the ICM. Status from other modules is documented elsewhere and in the manuals for the modules. This brief also tells how to use the status command to obtain the value of an IOM port, a capability available in 3220119V and above. LIMITATIONS and OPERABILITY Since this is a feature-in-progress, some parts of the intended scope are not yet implemented. Some status items not fully implemented may return 0 or other invalid values. The primary changes from the previous publication of this document are: status requests may now be 'persistent'. Persistence is established by using a new form of the load-status statement, LOAD/FROM/STATUS/BYTE. status is now obtainable from slave racks (caveats about delay after request are included below). At one time it was the intention that ALL status be persistent. Experience has shown that single-report status is useful, so it has been retained. Single use status is most useful (and least impacting on system bandwidth) for status that is only needed occasionally. Persistant status is particularly useful where some status must be used to trigger cues, as described in the next section -- the persistent update then permits the cue triggering without any 'maintenance' cue constantly running. Note however, that persistent status IS set up by cue statements -- it is not part of a rack's configuration. If a rack is reset manually, by a download of code or configuration, or by a power cycle, all the persistent status setup will be lost, and the master rack's cues will need to be re-run to provide the required direction to the slave racks. CUE CONTROL WITH STATUS Use of status for cue control (play/stop/reset) is indirect. As outlined below, the LOAD statement permits attaching a status to a variable, input byte or output byte, and these are then used as usual for cue control. CUE STATEMENT ACCESS TO STATUS The following statements are used to get status information: LOAD [@Vv,@Ii,@Oo] WITH @Rr,s[,p] STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] FROM @Rr,s[,p] STATUS n BYTE b-e ; where [@Vv,@Ii,@Oo] selects the destination for the status (in the 'syntax' pulldown in MP4000, this is [anyv]), @Rr,s,[,p] selects the source of the status n selects the status b-e gives the beginning and end byte to get "WITH" establishes a one-time request, "FROM" establishes a persistent delivery to the target In the source, if the port [,p] is not given, the status will refer to the module rather than one of its ports. Note that this generic form works also for cues and animation scenes, with @Qqqq or @Aaaa replacing the @Rr,s[,p]: LOAD [@Vv,@Ii,@Oo] WITH @Qqqq STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] FROM @Qqqq STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] WITH @Aaaa STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] FROM @Aaaa STATUS n BYTE b-e ; The value n is the 'index' to the status of interest in the set associated with the specified port @Rr,s,p or module @Rr,s. Using 0 for n always retrieves a set of status bits for the source; values 1 and higher are for data specific to the port or module. Some status items carry similar information from all modules and ports. The status item size may be 8, 16, or 32 bits, as detailed in the module manuals, along with the description of the corresponding status. This document describes status available from the ICM4020. Some status items may be arrays of identically sized values, e.g. LCM4020 item 6, DMX data. The statement format permits specifying which bytes of a status item are of interest. The BYTE token and b-e specifier are a way to control and/or limit what status is moved. As examples: 1) you may move the second byte of a long (4-byte) status into an input block byte, by using LOAD @I200 WITH @R0,17,0 STATUS 0 BYTE 1-1 ; or 2), you may load 16 DMX channels from the LCM card into 4 consecutive variables by using LOAD @V100 WITH @R0,5 STATUS 6 BYTE 20-35 Ordinarily, a BYTE range is used that correponds exactly with the size of the status: 8-bit status: BYTE 0-0 16-bit status: BYTE 0-1 32-bit status: BYTE 0-3 arrays of 8-bit: BYTE b-e APPLICATION INFORMATION The following statements are used to get status information (these are repeats of those given above): LOAD [@Vv,@Ii,@Oo] WITH @Rr,s[,p] STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] FROM @Rr,s[,p] STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] WITH @Qqqq STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] FROM @Qqqq STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] WITH @Aaaa STATUS n BYTE b-e ; LOAD [@Vv,@Ii,@Oo] FROM @Aaaa STATUS n BYTE b-e ; We do not currently foresee any other forms. See also LIMITATIONS, above. The following statement releases the variable, input byte or output byte for normal use: UNLOAD [@Vv,@Ii,@Oo] ; PERSISTENT STATUS The LOAD/FROM statement establishes a 'connection' from the specified status to the selected object (variable or byte). Once a LOAD statement of this sort has been issued, the selected object is updated routinely and at change by the ICM, over the network if the status item is remote. For items outside the master rack, there is some delay in initiating the update sequence, so a DELAY will be needed after LOAD statements. The delay ranges from about 2 frames for systems with two or three slave ICMs to about 10 frames for systems with a full complement of 31 racks. [This recommended/necessary delay applies also to single-report LOAD/WITH statements sent to slaves, since the messaging operations are the same, except that the trigger is shut down after a single use.] After the routine update is established, the item will be updated within a frame of its change in small systems (four or less slaves) or within three to four frames in large systems (twenty-five or more slaves). This update rate may be affected if many status items from remote racks are LOADed. There is no delay for items in the master rack; in fact, the destination is updated for the first time immediately, as part of the execution of the LOAD statement. Each rack, master and slaves, can have up to 500 active status items, counting both persistent and any instantaneous load of single-report requests for status. Slave racks will transmit the value of status when the request is initiated, and then again whenever the status changes. The comparison with a previous value, inhibiting messaging if there is not a change of value, can only be done for status values of 4 bytes or less. If a selection from an array is made that is more than 4 bytes, the comparison will be overridden, and the status values will be transmitted to the master in EVERY frame. An UNLOAD command, or a LOAD/WITH, or another LOAD/FROM, to a destination of a persistent status, will cancel or modify the older 'connection'. There are comments about the UNLOAD command below. DATA MOVED, MORE ABOUT "BYTE b-e" The amount of data (the number of bytes) moved to the selected object is ordinarily the size of the specified data, even if a byte destination is selected. For example, an analog 'following error' would be typically two bytes. If LOADed to a variable, those two bytes are moved to the least significant two bytes of the variable, and the other two bytes of the variable are set to zero. If that following error is LOADed to an output byte, both bytes are moved: the least significant byte to the specified output byte, and the other byte to the NEXT output byte in order. The required BYTE b-e argument is used to specify a number of bytes to use from the specified status item. The b-e 'range' parameter gives the first (beginning) and last (ending) byte of the status item to move to the destination. These first/last values must be within the specified status item. Bytes are numbered 0-based, so an 8-bit item has byte 0, a 16-bit status item has bytes 0 and 1, and a 32 bit status item has bytes 0, 1, 2, and 3. For example, to pick out the second byte from a DSM's port status that contains the 'playing' bit, use LOAD @I710 WITH @R0,3,2 STATUS 0 BYTE 1-1; The bit is then tested with IF @I710.4 = 1 GOTO Playing;. Note that these examples are made up; use the module's manual to find the exact status item, byte, and bit to use. An array of status items will have many bytes. To get some subset of the array requires that the BYTE parameter have the appropriate byte range specified. For example, the LCM status contains an array of the output DMX data. To access, say, lighting channels 4 through 12, the statement LOAD @V32 WITH @R0,2 STATUS 6 BYTES 4-12; is used. This statement would map lighting channels 4,5,6, & 7 to variable 32; lighting channels 8, 9,10, & 11 to variable 33; and lighting channel 12 to variable 34. MULTIPLE DESTINATIONS Note that the same status may be LOADed to more than one destination. The maximum number of LOAD statements that can be active at any one time is 500 in every rack. The 'connections' can be UNLOADed and reLOADed dynamically as necessary. See UNLOAD, below. BAD SPEC HANDLING (not fully implemented) If n specifies a status item not defined by the module's header, the selected object will NOT be modified, and the 'connection' will not be established. A count of such attempts is kept and may be accessed by using the HMT or by using LOAD statements. A count is also kept of the number of active LOAD statement connections. See the description of ICM status items for access to these counts. THE UNLOAD STATEMENT The UNLOAD statement merely signals the system that the continual update is no longer needed. This is essentially a cleanup issue to help keep the net usage down. If a variable or byte is being reconnected from one status item to another status item, it is not necessary to use UNLOAD; the newly issued LOAD statement will effect the disconnection before initiating the new update sequence. If a destination is one of several involved in a persistent update (perhaps initiated with a wide byte-range on an array of data), then a LOAD to that destination will disconnect the ENTIRE original range in which it was included. Similarly, a new LOAD instruction to the same (or any contained) destination will cancel any previous connections to that destination. STATUS vs. FRONT PANEL SWITCH If the master rack's front panel switch is placed in the TEST position, ALL status reporting from the master and any slaves is stopped. The setups are not lost, so the reporting will resume when the switch is returned to the RUN or PROG positions. If a slave rack's front panel switch is placed in the TEST position, ALL status reporting from that slave is stopped. The setups are not lost, so the reporting will resume when the switch is returned to the RUN or PROG positions. APPLICATION NOTE It may be useful sometimes to retrieve only a portion of several bytes available. For example, in the 'download version' there are four bytes; the download number is in the least significant byte, and the download letter is in the most significant byte. For example, the download version 3220119U.COD is returned into a variable as (hex) 55000077. It may be easier to deal with in a cue if loaded into a byte variable with a 0-0 range, giving the (hex) 77 value, 119 decimal; or a 3-3 range, giving the (hex) 55 value (an ascii 'U'). Suppose you wish, at different times, to retrieve a different set of elements of a status array, for example, the LCM's DMX data. You can use a variable in the BYTE specification and reduce the number of statements in your cues. The following cue gets all the 512 DMX bytes from the LCM, one at a time, and sends them to the HMT: SET @V99 TO 0 ; SET @V100 TO 1-1 ; LOOP: LOAD @V101 WITH @R0,5 STATUS 6 BYTE @V100 ; DISPLAY "%d101" ; INCREASE @V100 BY 1-1 ; V100 becomes 2-2, 3-3, etc. INCREASE @V99 BY 1 ; IF @V99 < 512 GOTO TOP ; ======================================================================== STATUS INDECES (n) FOR ICM4020 MODULE AND PORTS (* indicates items that are not functional as of date of writing) ======================================================================== CUE STATUS (with @Qqqq) index item bytes 0 CUE_BIT_STATUS 0-3 * 1 CUE_STATE 0-0 2 CUE_FRAME 0-3 3 CUE_SYNC_FRAME 0-3 4 CUE_RATE 0-0 CUE_STATE values: 0 = stopped 1 = playing 2 = delayed 3 = waiting 4 = holding (SMPTE) SCENE STATUS (with @Aaaa) 0 SCENE_BIT_STATUS 0-3 * 1 SCENE_STATE 0-0 2 SCENE_FRAME 0-3 3 SCENE_SYNC_FRAME 0-3 4 SCENE_RATE 0-0 5 SCENE_TCM_ERROR_COUNT 0-1 SCENE_STATE values: 0 = stopped 1 = playing 2 = stepping 3 = update (internal operation) 4 = waiting (SMPTE) 5 = synch'd (SMPTE) ICM MODULE STATUS (with @R0,17) 0 ICM_BIT_STATUS 0-3 1 BOOT_VERSION 0-3 2 DOWNLOAD_VERSION 0-3 3 FRONT_PANEL_SWITCH 0-0 4 MEMORY_CAPACITY 0-3 * 5 RESET_COUNT 0-1 * 6 RESTART_COUNT 0-1 * 7 NUMBER_OF_CUES 0-1 8 RAM_CUE_COUNT 0-1 9 CUE_ERROR_COUNT 0-1 10 EVENT_ERROR_COUNT 0-1 11 NUMBER_OF_SCENES 0-1 12 NUMBER_OF_OCCUPIED_SLOTS 0-0 13 SLOT_CARD_TYPES (array) b-e b,e 0-16 The ICM_BIT_STATUS bits presently supported are: bit 2 ESTOP_BUS bit 3 CONST_BUS bit 4 Delayed5V ICM PORT 0 STATUS (with @R0,17,0) 0 ICM_PORT0_BIT_STATUS 0-3 * 1 FRAME_OF_DAY 0-3 2 YEAR 0-1 3 MONTH 0-0 4 DATE 0-0 5 DAY 0-0 6 HOUR 0-0 7 MINUTE 0-0 8 SECOND 0-0 9 VIDEO_SYNC_COUNT 0-3 10 VIDEO_SYNC_RATE 0-0 * 11 SYSTEM_FRAME_COUNT 0-3 Note that the FRAME_OF_DAY may be DISPLAYed with the %T attribute to get a time-of-day output to the HMT, if you don't mind having the running frame number at the end. The internal clock (hardware or firmware) is SET with statements addressing port 0. A separate brief is available concerning the on-board clock and the beeper. ICM PORT 1 STATUS (with @R0,17,1) 0 ICM_PORT1_BIT_STATUS 0-3 bit 7 of this status indicates that an HMT key is available to load (see status 11); this bit is cleared when the load of status 11 is done. 1 NET_ONLINE_BITS 0-3 2 UPDATE_ERROR_COUNT 0-1 3 PARALLEL_CS_ERROR_COUNT 0-1 4 PARALLEL_RESET_COUNT 0-1 5 MP_NET_ERROR_COUNT 0-1 6 MP_NET_RECOVERY_COUNT 0-1 7 ANIMATION_SUCCESS_COUNT 0-1 8 COMMAND_SUCCESS_COUNT 0-1 9 SYNC_SUCCESS_COUNT 0-1 10 UPDATE_SUCCESS_COUNT 0-1 11 LAST_HMT_KEYPRESS 0-0 this keypress status is not updated while the HMT is in the maintenance menu set, and idles at 27 (ESCape) during this time. IOM STATUS (IOM port values) 0 reserved 1 reserved 2 VALUE_IOM_PORT Note that if status VALUE_IOM_PORT is chosen for port 0 with a byte range of 0-1, then both port values will be returned. ------------------------------------------------------------------------ Specifications subject to change at any time. The data in this document incorporates proprietary rights of Anitech Systems Inc., 25021 Anza Drive, Valencia, CA 91355 USA. Phone (661) 257-2184 Fax (661) 257-2025 email Mail@Anitech-Systems.com Web http://www.Anitech-Systems.com Any party accepting this document does so in confidence and agrees that it shall not be duplicated in whole or in part, without the consent of ANITECH SYSTEMS.