3/24/98 12/11/98 LCM_DL.DOC Release OK The Anitech Systems LCM4020 PCMCIA-Capable Lighting Control Module A Brief Outline Of Module Operations And Capabilities The Hardware The LCM4020 has one input (receive) DMX serial port, and five output (transmit) DMX serial ports (all transmitting the same DMX data). There is a PCMCIA socket to hold a hard-disk (typically) of suitable size for the files that define the lighting cues, downloaded to the LCM4020 by the MP4000 software. A front panel switch has PROG, TEST, and RUN positions. An RJ11 jack permits attachment of a hand-held terminal or computer for monitoring, and is an optional connection for use of the MP4000 Software. There are eight indicators for module activity: DMX transmit and receive, monitor serial transmit and receive, a PLAY indicator, a RECORD indicator (used during real-time recording, also doubles as a disk-activity indicator), a COM indicator (blinks to show normal board operation and messaging on the backplane from the ICM) and a PGM indicator (used during downloads, also doubles as an error indicator). The System View The LCM4020 provides 32 'ports' of lighting control. This use of the word 'port' is congruent with the Media Pro 4000 use, in which a 'port' on a 'module' is a means to access some resource on the module. For example, an IOM has two ports, each being eight discrete outputs; the ASM has eight ports, each being an analog servo loop; and so on. Each of these 32 ports has 512 lighting channels of its own. The value that a port has for a lighting channel has an effect on the transmitted DMX data only if it is bigger than every other port's 'bid' for that channel, an operation called pile-on. The largest 'bid' gets to the output set. There is no patch table in the LCM. A Brief Glossary The word 'cue' is used with the LCM4020 operation in a manner consistent with its use in 'lightboards', referring to a control definition that permits the lightboard to repeatedly generate a lighting sequence, with channels, levels, and times associated. A lighting cue in the LCM may also be a 'real-time' recording of DMX data supplied from a lightboard. This document usually uses the full reference 'lighting cue'. The word 'cue' is also used with the Media Pro 4000 system to refer to a script that runs in the ICM to provide control for the entire system. Certain 'statements' in these ICM cues control activities of the lighting control module, but it is important to not confuse the 'lighting cue' (that operates in the LCM4020) with the Media Pro Control Language cues that direct the activities of the ICM and the system as a whole. This document attempts to avoid the possible confusion by referring only to 'statements' that can be used in the MPCL cues. What An LCM4020 Port Can Do Any port can play a lighting cue (a 'look' or a 'real time' recording) from the on-board PCMCIA disk, can execute 'RAMP' statements from a Media Pro 4000 cue, or can be configured so that some of its lighting channels can be destinations for animation data. The port can do all of these simultaneously; to resolve conflict, the activities have a precedence: cues, ramps, and animation, in that order of priority. This is not typically an issue, since it is likely that ramps and animation would be executed in ports that are not playing lighting cues. [Note that in the near future the priority of ramps will be changed so that they will be independent of lighting cues. The remainder of the document may contain references to the priority that reflects the operation as it is now, as of LCMDL272.] The ports are independent. One port may be running a cue on a channel, a second can be running a ramp on the same channel, and a third may be animated in that channel - there is no conflict, and the pile-on operates so the largest 'bid' gets placed in the output stream. Lighting Cue Sequencing Lighting cues are created and placed on the PCMCIA disk using the LCM-4020 Edit Options dialog in the MP4000 software. Up to 511 cues may be defined for each port, within the limits of disk capacity. (Unless recorded cues become significant, these will fit on almost any moderately sized PCMCIA hard drive. The disk must be, and remains, 'DOS'-compatible; there is a subdirectory for each port, and these are created automatically during downloads.) When the LCM initializes, any port for which cues are defined executes a 'seek' to the numerically first cue in its set. Since no other cue is then active in the port, this first cue becomes the 'active' cue, but does not yet 'play', the port being in its 'idle' state. (Note that this 'idle' state happens ONLY this once, out of reset/initialize activities.) The port will then determine the cue in next numerical order (or use the reference to a 'linked' cue from the active cue), and prepare that cue for use after the active cue completes. This second cue is said to be pending. Thus, a port with defined cues always has an active cue (whether its playing or not) and a pending cue. After this initial setup, the operation of the LCM port is controlled by statements in MPCL cues. Cue sequencing is controlled with RESET, PLAY, STOP, SEEK, STEP, and STEP REVERSE. Individual port channels (or groups of channels) can be controlled with the RAMP statement. (The SET statement is not used for establishing channel values; the LOAD command is reserved for host MP4000 use in setting up for recordings.) Please see the 'Considerations...' section later for more details about the port initialization in the LCM. The active cue's state can be idle, playing, stopped, or complete. If idle or stopped, the PLAY command will cause the cue to proceed. When the cue ends, it becomes 'complete'. If the pending cue was 'linked' to the active cue, that pending cue will become active and will play immediately. The next numerical cue or the new linked cue will become the new pending cue. If the pending cue is not 'linked', the active cue will merely remain in its 'complete' state. (Note that during this time its channel set will continue to affect RAMPs and animation as described below.) While idle (a state that can happen ONLY out of reset), the PLAY and STEP statements have the same effect - the active cue plays. While a cue is playing and not yet complete, the PLAY statement has no effect. While playing, the STOP statement suspends the cue (not including any attached RAMPs); while stopped, the PLAY statement makes the cue continue. When the active cue in the port is 'complete', the PLAY and STEP statements have the same effect - the pending cue is made active, and it plays immediately. A new pending cue is determined and made ready. Precedence In The LCM4020 As was mentioned earlier, the lighting channel behaviors specified in an active cue override any ramp directives from statements, and also cause animation to be ignored, for any channels in the active channel set. This lockout of ramps & animation persists even after the cue is completed (i.e. the wait time, up time and down time are all expired), until the port is reset (see below) or a cue becomes active that does not include the channel for which a RAMP operation might be desired. RAMPs are 'overloaded' on the active cue, if any, and may be initiated at any time; a RAMP established on a channel will take effect immediately, and run until complete. A RAMP in a channel causes animation for that channel to be ignored until the ramp operation is complete. Only when a channel is not in use for a lighting cue or RAMP operation, will animation from the ICM have any effect on it. Media Pro Control Language Statements For The LCM4020 (BE SURE TO READ THE 'Considerations...' SECTION FOLLOWING THIS) These basic MPCL statements are used to control the LCM from cues: RESET @Rr,s,p ; causes all the lighting channels in a port to be set to 0, there is no active cue and no pending cue.. If any channels for the port are 'animated', the animation data will have effect at the beginning of the next frame. Any ramps in progress will be terminated, but after reset, ramps can be initiated in ANY channel. RAMP @Rr,s,p CHANNEL [cc, bc-ec] TO pp IN tt ; where cc is a single channel specification, bc-ec is a range specification (begin channel to end channel, inclusive), pp is a percentage 0-100 of full on, and tt is a time expressed in 10th of seconds (even though the internal ramp rate is 30ths of seconds) from 0 to 99.9 seconds. Note that RAMPs cannot be initiated in a port for channels that are part of the lighting cue currently active in the port. SEEK @Rr,s,p TO lc ; preemptively activates the specified lighting cue, replacing the currently active cue; if the new cue is recorded, the first set of data is immediately loaded to the channels, and playback commences (there is no 'ease-in'); if it is a timed cue, operation begins immediately. The preemption and play happen regardless of the current state of the currently active cue, idling, playing, stopped, or complete. This command will stop any RAMPs in progress that conflict with the new active channel set, and animation will be ignored for channels that are in the active channel set. PLAY @Rr,s,p ; resumes operation of currently active lighting cue if STOPed; or, if the active cue is 'complete', makes the pending cue active and plays it. Note that PLAY has no effect on an active cue that is already 'playing'. It will not immediately execute the link in the active cue - see STEP, below. STOP @Rr,s,p ; suspends a currently active lighting cue in the port - the timers and channel values pend, and will continue operation with a later PLAY command. RAMPs are not stopped, nor is any animation that is configured for the port (although note that animation configured for channels that are in the lighting cue's channel set, and which is therefore being ignored, will continue to be ignored while the lighting cue is STOPed, and RAMPs are inhibited also for those channels. A recorded lighting cue is held at the current frame, and will continue playback with a later PLAY statement. A port that is 'complete' will ignore the STOP statement. STEP @Rr,s,p play the pending cue; this works even if the port is currently playing a cue. The pending cue is either the linked cue from the current cue, or the cue in next numerical order. Note that the last cue (i.e., with the highest number) for the port has no 'next' cue unless it has a link. STEP @Rr,s,p REVERSE play the previous cue; the selection is NOT in order of play, reversed, but the cue with the numerical sequence less than the current cue is determined and played. Considerations About MPCL Statements For The LCM4020 1. Avoiding disk access delays in cue sequencing: Note that the SEEK command always generates disk access activity that opens the cue before it plays. Thus, using SEEK statements in the MPCL cues for all lighting cue sequencing will be relatively inefficient. [Firmware versions with 272+ sidestep this issue somewhat by merely PLAYing the cue specified in a SEEK command if it is already available as the next cue.] The PLAY and STEP commands avoid this delay, because the LCM always prepares the 'next' cue for play by performing disk access operations 'in the background' during the play period of the current cue. When a PLAY or STEP is executed, the ALREADY initialized next cue becomes active immediately without any disk access delay, and a new 'next' cue is opened. Do note, however, that the PLAY command will not abort the currently running cue in the port, but the STEP command will. 2. Waiting for LCM Initialization After Power-on or Reset: When reset, or at the end of a firmware download, the LCM executes an initialization sequence, investigating the disk and preparing internal tables that speed later operation. Every cue file on the disk is found, and its location and type saved for later use. The operation can take a considerable amount of time, up to a few dozen seconds. During this time, the LCM can handle communications, but the ports are not ready for any of the ordinary cue sequencing operations, and these should be avoided. Most commands that might come from ICM MP4000 cues are merely ignored during this time, but they are then lost, and the effect desired by the programmer will have been missed. The LCM will provide an init-complete signal by blinking the PLAY & REC indicators, and beeping, when it is ready to begin normal operations. The MPCL cues written to control it should not be run until after the initialization is complete. In the near future, an LCM status bit will be available to indicate that the LCM is ready or not-ready for operation. Configuration For Animation Animation for the LCM4020 is defined on the 'LCM Configuration' dialog in the MP4000. This dialog permits assigning a contiguous range of animation channels (abbreviated 'Chan') to each of the ports. The 'DMX' column identifies the lighting control channel in the port. The data animated to these channels pile-on with the other ports' lighting control channels. RECORDING WITH THE LCM The LCM cue edit dialog in the MP4000 software is used to create lighting cue files on the PC which are then (or later) downloaded to the LCM's disk. Timed cues contain the data values established by the programmer, and recorded cues are pre-filled with 0's. The LCM will record only to a file which is already on its disk. To record a file, it is first selected from the MP4000 by clicking the GOTO button and the STOP button while in the PORT view. Then the incoming DMX is selected, and the record operation is set up by clicking on the REC button. Finally, when ready, click on the GO button and the LCM will fill the file with the incoming DMX data. Remember that the file on the LCM disk is now different than the file on the PC, and should be uploaded when convenient after the programmer is satisfied with the recording. LCM STATUS The LCM port and module status can be accessed by MP4000 statements for use by MP4000 cues and to control cues (PLAY/STOP/RESET). The LOAD statement shown 'connects' a status to a variable or to a byte in the input/output blocks: For ports: Into variable: LOAD @Vv WITH @Rr,s,p STATUS n BYTE b-e ; Into input byte:: LOAD @Ii WITH @Rr,s,p STATUS n BYTE b-e ; Into output byte: LOAD @Oo WITH @Rr,s,p STATUS n BYTE b-e ; For module: Into variable: LOAD @Vv WITH @Rr,s STATUS n BYTE b-e ; Into input byte:: LOAD @Ii WITH @Rr,s STATUS n BYTE b-e ; Into output byte: LOAD @Oo WITH @Rr,s STATUS n BYTE b-e ; The number n is the 'selector' for the status of interest, per the list given below. Each status item may be a byte (8-bits), an integer (16-bits), or a long (32-bits), or an array of any of these types. Status cannot be specified to the bit level - this requires an 'IF' test of the loaded object in a cue. After one of these LOAD statements is executed, the specified status item is moved repeatedly into the selected destination repeatedly, routinely and at change. The BYTE parameter permits limiting the move, in case the source is bigger than the destination, and is NOT optional. For example, to move the LCM's disk size (a long) into variable #100, use LOAD @V100 WITH @R0,2 STATUS 5 BYTE 0-3 ; or, to pick up a handful of DMX data: LOAD @I100 WITH @R0,2 STATUS 6 BYTE 30-39 ; which will put the ten specified DMX data values into I100, I101, I102 ... I109. The LCM Status Indeces for the ports: INDEX n Item 0 16-bits bit status for port bit 1 not_configured, bit 2 estopped, bit 3 animation_disabled, bit 4 set_disabled, bit 5 ramp_disabled, bit 6 output_disabled, bit 7 port_command_error, bit 8 cue_pends, 1 16-bits current cue 2 16-bits pending_cue for the module 0 16-bits bit status for LCM module bit 3 module_running_download, bit 4 estop_bus, bit 5 constant_bus, bit 6 delayed_5v, bit 7 hardware_problem, bit 8 no_download, bit 9 no_configuration, bit 10 no_parameters, bit 11 module_command_error, bit 12 pcmcia_device_present, 1 16-bits boot version 2 16-bits download version 3 16-bits disk manufacturer code 4 16-bits disk manufacturer info 5 32-bits disk capacity 6 8-bits piled-on DMX data (array of 512 bytes)