_____________________________________________ ADAM MCII-e Master Controller - Version 2.2.2 _____________________________________________ Code image CRC Standard: 9e0f Japanese: Not yet released Files: MCII-e.hex - Motorola S-record file for downloading to the MCII-e board flash via an AZedit connection to the MCII-e board. The MCII-e board must already be running a version of either the single frame MCII-e Master Controller or the multi-frame MCII-e Peripheral Controller firmware. MCII-e.srec - Motorola S-record file for downloading to MCII-e RAM using the Altera GERMs monitor and the Altera "nios-run" utility. (used for installing on a new MCII-e card without any existing firmware). ______________________ Supported System Sizes ______________________ This firmware supports the following configurations: - Single frame - Non-redundant multi-frame systems: 2 to 8 frames - Redundant multi-frame systems: 2 to 6 frames The largest system size supported is 880 ports. _____________ Compatibility _____________ This version of firmware supports single and multi-frame configurations. Multi-frame communications requires MCII-e controllers (with identical firmware) in each frame, and Tri-Bus Expanders for passing audio between frames. MCII-e Master Controller Requires MCII-e version 2.2.2 in all frames, for both active and standby controllers. See the following section for details. The MCII-e will come up with a blank setup when upgrading from version 2.1.x or earlier, but will remember the system size. AZedit: Requires AZedit v3.6.2 or later. Requires AZedit v3.8.0 for full support of all features, including configuring MADI cards and configuring MC/TM communications via Ethernet. Requires a Unicode release of AZedit for full support of all features in a Japanese build of the intercom. AIO-8 Card: Requires AIO-8 version 10.3.0 or later. Requires AIO-8 v10.3.6 or later for support for KP 32 CLD colors. AIO-16 Card: Requires v1.1.0 or later. Requires v1.1.1 or later for Kanji support. Multi-frame systems larger than 864 ports require AIO-16 v1.1.4 or later. RVON-8 / RVON-16 Card: Will work with any version of the RVON-8 or RVON-16 firmware. Multi-frame systems larger than 864 ports require RVON v2.1.6 or later. MADI Card: Requires v1.0.0 or later. Tri-Bus Expander: Requires v0.0.5 or later. UIO-256: Requires version 2.0 (checksum 78b5), with the UIO-256 configured in multi-drop mode (DIP switch S1 position 2 closed, and with the RS-485 data going to J2 of each unit). GPIO-16: Requires version 0.0.3 or later. PAP-940/951/952: Requires version 7.3.x or later. PAP-32: Requires v0.0.3 or later. ARP-32: Will work with any version of the ARP-32. ARP-32 panels are only supported in single-frame configurations. Trunk Master: Requires v7.3.0 or later. Requires v8.6.0 for support of IFB Special Lists across trunking. Requires v8.8.0 for support of more than 120 resources (other than ports) across trunking. Requires v8.9.0 for MC/TM communications via Ethernet. Standard Master Controller: Not supported. Single Bus Expanders: Not supported. Dual Bus Expanders: Not supported. _____________________________ Upgrading Multi-Frame Systems _____________________________ For normal operation, all controllers in the system must be running version 2.2.2. Within one frame, there are no compatibility problems between version 2.2.1 and version 2.2.2. If the (active) controllers in different frames are not both v2.2.2, then remote alphas will not be transferred from frame 1 to the other frames. Other than this, there are no compatibility issues between v2.2.1 and v2.2.2. If the active controller in one frame is v2.2.2, and the active controller in another frame is v2.2.0 (or older), the controllers will communicate with each other, and transfer the configuration between them; a lot of the intercom operation will appear to work. However, some information (e.g. keypresses) might not be forwarded between frames, and hence normal inter-frame communications may not be possible. ___________________ DIP Switch Settings ___________________ Position Description -------- ----------- 1 Must be open (closed => boot to GERMS monitor) 2 AZedit (J1) baud rate: open=9600, closed=38400 3 Should be open (reserved) 4 Should be open (reserved) 5 Must be open (closed => enter test mode) 6 Must be open (closed => don't reprogram flash after download) 7 Should be open (reserved) 8 Must be open (closed => enter test mode) ____________ Installation ____________ If the MCII-e board is already running MCII-e firmware, the "MCII-e.hex" file can be downloaded to the card via AZedit. Otherwise, the Nios_Loader utility can be used to download a new image and copy it to flash. ______________________________________ TM Connections for Multi-Frame Systems ______________________________________ For a multi-frame Tri-Bus system, only the lowest-numbered frame (the "primary") frame connects to the Trunk Master. This would typically be frame #1. If frame #2 does not have an Ethernet link to frame #1, it will try to establish its own connection to the Trunk Master. When the intercom is configured to use a network connection to the TM, the behavior is determined by the check-box labeled "Autonomous frames connect as distinct intercoms" on the Trunk Master Communications dialog in AZedit. If this box is not checked, then frame #2 will try to connect to the TM in place of frame #1. If successful, everything looks the same, except that the TM is now communicating with frame #2 instead of frame #1. If this box is checked, then frame #2 will try to connect as its own distinct intercom. For this to work, the Trunk Master would have to have the IP addresses for the frame 1 controllers associated with one matrix, and the IP addresses for the frame 2 controllers associated with a second matrix. This could be used to set up a disaster recovery scenario. Two frames would normally operate as a single intercom. However, if the fiber links between them were lost, they could fall back to operating as 2 distinct intercoms, each with its own connection to a Trunk Master, using pre-defined trunks between the frames (using a different transport mechanism, such as RVON). To be effective, this would require the configuration option "Force Autonomous Mode when no audio links up" to be enabled. ______________ Change History ______________ New in version 2.2.2 -------------------- * Fixed problem listening to remote IFB via AT If a panel is listening to one remote IFB via AT, and then the trunk is reallocated so that the panel listens to a different IFB via AT, the audio might not be switched properly. In this case, the panel would continue to hear the original IFB listen source, and it would be difficult to clear, since that IFB assignment no longer appeared as a key assignment on the trunk port. (Also, the panel would have to toggle the IFB listen key off and on before it would start hearing the new IFB listen source.) Fixed. Note that this problem was not easy to generate. It would typically occur when changing setup pages (or sending a new AZedit setup file) that resulted in changing the IFB assignment of a talk key while the listen key (with an AT assignment) was already on. * Remote alphas transferred properly to slave frames For large systems (larger than about 750 ports), slave frames could end up with incomplete remote scroll lists. Fixed. (The work-around was to go to Status | Ethernet Links | Frame-to-Frame, and then reset the links between the frame 1 active controller and the active controller in each of the other frames.) * Fixed I/O card error counters The I/O card error counters shown in AZedit always reported as 0, for cards in any frame other than frame 1. Fixed. * UPL force-key actions cannot touch trunk ports In previous versions, a UPL statement with an output action to force a key on or off could interfere with trunking operation. Fixed. New in version 2.2.1 -------------------- * If one frame loses communications with another frame, keys for panels in the other frame used to be forced off after 60 seconds. Fixed. Now keys in the other frame are not forced off automatically. (They can be cleared via AZedit.) * When starting a firmware download, AZedit now reports that the devices in a specific frame are unavailable for download if that frame is currently receiving the intercom configuration as part of the resynchronization process. * In a system of 3 or more frames, if AZedit were connected to a frame other than frame 1, Status | Master Controller could show frame 1 as being up to date, even if it was receiving the intercom configuration from another frame as part of the resynchronization process. Fixed. * Remote alphas were not always being transferred to the standby controller. Fixed. * When two frames start communicating, they exchange configuration information, including which talk and listen keys are on. However, some key status information was not being handled properly, with the result that one frame might not show the correct talk or listen key status for panels in the other frame. (This was typically harmless. It would usually only be for higher-numbered listen keys, and would not result in any spurious audio.) Fixed. * If a transfer of control occurred when the standby was not up to date, I/O card type information (e.g. is a card an RVON-8?) could be lost. Fixed. New in version 2.2.0 -------------------- * Support for TM-2000 communications via Ethernet The intercom now supports communications with the TM-2000 via either serial or Ethernet. This can be configured from AZedit via Options | TM Communications. If serial communications is selected, the baud rate can be set from this dialog, rather than needing to reconfigure the intercom. If Ethernet communications is selected, you must specify the IP address of the TM-2000 (and also the IP address of the backup TM, if there is one). * Support for MADI cards A new screen allows MADI cards to be configured. This screen has 3 tabs. One tab allows card attributes to be configured (pass-through data, reference clock, sampling rate, etc. Another tab controls the mapping between intercom channels and MADI channels. The third tab displays the status of the various MADI cards in the system. * Full support for Command-Line Protocol In previous versions, only a subset of CLP requests were supported for multi-frame intercoms. Starting with v2.2.0, there is full support for CLP. * Support for new frame-to-frame link status display This version supports a new AZedit screen, Ethernet Link Status. This screen shows, for the controller to which AZedit is connected, the status of the links to each other frame. * Support indefinite tallies across frames When making a point-to-point call, indefinite tallies (i.e. tallying for as long as the caller's talk key is on) was only supported when both the caller and the target were in the same frame. * Improved frame-to-frame communications It was possible to get into a state in which two frames were talking, but were not being synchronized; changes sent by AZedit connected to one of the frames would not be reproduced in the other frame. Fixed. * Ensure RVON-IO gets local GPIO status If an RVON-8 or RVON-16 is reset or plugged in, and that RVON card has links to 1 or more RVON-IO cards, the RVON-IO card might not get the status of the local GPI outputs for its ports, if there is no keypanel attached. Fixed. * AZedit could warn of configuration flash update failure When sending changes to the intercom, AZedit will generate a warning if the configuration was not properly saved to configuration flash (e.g. if there was a write failure to the device). However, it could sometimes generate this message just because the controller timed out waiting for access to the configuration flash (because another low-priority task was updating the flash already). Fixed. When activating changes, the intercom should always get access to the configuration flash. New in version 2.1.2 -------------------- * Remote alphas scroll lists were sometimes not completely transferred to slave frames. In particular, the first 30 or so items would always be available, but higher-numbered items might not be available. (AZedit and keypanels connected to the slave frame would show a generic alpha, such as 285N.) However, key assignments could still be made from an AZedit session connected to frame 1. Fixed. * On an incoming trunked call from a remote intercom, if the called panel was not in frame 1, it would not receive an incoming call tally. Fixed. * If a key was reprogrammed at the panel using the keypad, and that key was on (e.g. because of an All-Call), other frames might not handle the audio switching properly. Fixed. * When sending changes, AZedit would sometimes get stuck showing the "Activating changes" message, requiring that it be killed via the Task Manager. (It was possible to recover by disconnecting AZedit from the intercom, e.g. by disconnecting the computer's network cable until AZedit timed out.) Fixed. * It was possible to get the system into a state where changes could not be sent to the intercom; AZedit would report that it could not obtain exclusive control. It would be necessary to force a transfer of control in one of the frames to recover. Fixed. * In certain circumstances, the active controller in a frame could reset. Fixed. New in version 2.1.1 -------------------- * Added support for configuring KP 32 CLD talk & listen indicator colors The KP 32 CLD now uses a bar at the bottom of a key to indicate that the talk key is on, and a bar at the top of a key to indicate that the listen key is on. These indicators are red and green, respectively, by default. AZedit allows the colors of these indicators to be configured. * Remote alphas transferred to standby Remote alphas (received from the Trunk Master) are now transferred to the standby controller. In the event of a transfer of control, the intercom and the Trunk Master should resynchronize much more rapidly, since the Trunk Master no longer has to download all the alphas to the intercom. * Added verification that I/O cards have the right crosspoints closed The MCII-e continually verifies that the I/O cards and the DBX agree on which crosspoints should be closed. This guards against stuck crosspoints in the event of a message delivery failure. * Eliminate active/standby errors at start-up If both controllers in a frame were reset within a few seconds of each other, the active controller could record a burst of errors when the standby started communicating. Fixed. New in version 2.1.0 -------------------- * Added support for KP 32 CLD color tables The intercom supports the following data: - default key assignment colors (per function type) - remote key assignment colors (per remote matrix + function type) - local key assignment colors (per local assignment) * Added ARP-32 support (single-frame only) The ARP-32 is now supported when the intercom is configured as a single-frame system. * Support for more resources across trunking Remote scroll lists of up to 1000 items are now supported. * Support for more total resources In previous versions, an intercom was limited to approximately 2040 total local scrollable resources (key assignments). This has been increased; now, the total number of resources is only limited by the available memory, although each scroll list (PL, IFB, etc.) is limited to a maximum of 1000 items. * Fixed active/standby issues When a frame was powered up, the system could get into a state in which the active controller would not keep the standby controller up to date. Fixed. * Improved frame-to-frame communications Various improvements have been made to frame-to-frame communications. * Fixed AZedit query: Assignment Groups - "Members Only" flags AZedit could sometimes display the wrong value for the "Members Only" flag of an assignment group. Fixed. New in version 2.0.5 -------------------- * Support for Arbitrary Crosspoints An optional crosspoint (input port and output port) can be associated with each UPL Resource. If a crosspoint is defined, then that crosspoint is closed whenever any panel is talking or listening to that UR assignment. There is also a Reciprocal flag. If this flag is checked, then the reciprocal crosspoint (from the output port to the input port) is also closed. If a user at a keypanel tries to adjust the volume of a UPL Resource, it adjusts the volume of the crosspoint (if it is defined). The volume of the reciprocal crosspoint is not affected. * Improved frame-to-frame synchronization When two frames start communicating, one frame will resend its configuration to the other, to ensure they have the identical setup. AZedit could briefly disconnect from the intercom while the frames were synchronizing. Fixed. * Fixed search-and-replace problem In certain circumstances, performing a search-and-replace could cause the controller to reset, if the assignment being searched for was replaced by itself. * Fixed controller reset problems Certain error conditions could erroneously cause the controller to reset. Fixed. * Improved handling of frame mapping tables When two frames start communicating, they compare their frame mapping tables, and merge them if possible. In rare cases, this could result in the same entry appearing multiple times. Fixed. New in version 2.0.4 -------------------- * Support for autonomous frame operation in multi-frame systems This firmware is based on version 1.6.2 of the ADAM MCII-e. However, it supports both single-frame and multi-frame systems. In a multi-frame system, the firmware supports autonomous operation: If any frame is disconnected, the other frames continue to work without interruption. Further details of autonomous frame operation are included in a separate document. * Automatic fail-over on loss of Ethernet If the active controller loses all of its Ethernet links to controllers in other frames, but the standby still has Ethernet connectivity, an automatic transfer of control is performed. * Force autonomous mode if no Tri-Bus audio links (option) As part of the intercom reconfiguration dialog, a new option allows the intercom to be configured so that a frame automatically enters autonomous mode if it has no audio links to other frames. In this case, it ignores the other frames (even if it has Ethernet connectivity to them) and operates in stand-alone mode. * Support for Centralized Auto-Dials The intercom supports up to 999 centralized auto-dials. Associated with each auto-dial is an alpha, a scroll restrict flag, and a telephone number. Auto-dial number NNN can be accessed by dialing the sequence #NNN (Dial "##" to generate a single "#" DTMF tone.) Centralized auto-dial numbers can also be accessed via the TIF dial menus in the KP32 and the KP32CLD, for keys which have an assignment for which the "Port is a TIF" flag is set. This requires the following minimum versions: - KP32 v2.1.1 - KP32CLD v1.0.4 * Support for Enhanced Assignment Groups Associated with each Assignment Group is a new checkbox, "Members Only". If this box is checked, then only keypanels that are members of the assignment group can access the assignment group. If the box is not checked, any keypanel can access the assignment group. * Support for Alarms The intercom automatically logs various error and alarm conditions (e.g. loss of communications with the Trunk Master; no backplane clock; no audio between a pair of frames). These alarms can be viewed from AZedit via the menu option Status|Alarms. A new pane in the AZedit status bar shows how many alarms are outstanding, and is highlighted whenever a new alarm occurs. * Support for Uploading Debug Information to AZedit In the event of a controller failure, information about the failure is recorded in flash memory. In this case, the AZedit menu item Options|Upload Debug Information is highlighted. Selecting this item allows the debug information to be uploaded and saved to file; it can then be provided to Telex to determine the cause of the problem. * Support for Logging in any frame Each frame generates log information independently. Enabling or disabling logging affects all frames. However, when configuring the log destination (which AZedit session receives log information), each frame can be configured to send its logging information to a different AZedit session.