_____________________________________________ ADAM MCII-e Master Controller - Version 2.6.2 _____________________________________________ Code image CRC Standard: dc44 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.6.x 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.5.x or earlier, but will remember the system size. AZedit: Requires AZedit v3.6.2 or later. Requires AZedit v4.2.0 for full access to all features. AIO-8 Card: Requires v10.3.0 or later. Requires v10.3.6 or later for support for KP 32 CLD colors. Requires v10.4.0 for support for KP 32 CLD panels with a separate call-waiting window. Requires v10.5.0 for support for Unicode Alphas in non-Japanese builds. Requires v10.6.0 for support for more than 64 keys per port. AIO-16 Card: Requires v1.1.0 or later. Requires v1.1.1 or later for Kanji support. Requires v1.1.4 for multi-frame systems larger than 864 ports Requires v1.2.0 for support for KP 32 CLD panels with a separate call-waiting window. Requires v1.3.0 for support for Unicode Alphas in non-Japanese builds. Requires v1.4.0 for support for more than 64 keys per port. RVON-8 / RVON-16 Card: Will work with any version of the RVON-8 or RVON-16 firmware. Requires v2.1.6 for multi-frame systems larger than 864 ports Requires v2.2.0 for support for KP 32 CLD panels with a separate call-waiting window. Requires v2.3.0 for support for more than 64 keys per port. MADI Card: Requires v1.0.0 or later. Tri-Bus Expander: Requires v1.0.0 or later. UIO-256: Requires v2.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 v0.0.3 or later. PAP-940/951/952: Requires v7.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.1 for MC/TM communications via Ethernet. Requires v9.0.0 for support of IFB tallies across trunking. Requires v9.0.0 for full support of 2 TMs Requires v9.1.0 for support of IFB-SL tallies across trunking. Requires v9.1.0 to support taking trunks out of service. 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.6.x. If the active controller in one frame is v2.6.2, and the active controller in another frame is v2.2.x (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. If the active controller in one frame is v2.6.2, and the active controller in another frame is v2.4.0 (or older), most trunking data will not be transferred between frames. ___________________ 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.6.2 -------------------- * Fixed Ethernet communications problem The MCII-e maintains the following Ethernet connections: - Connections with every other frame (for a multi-frame Tri-Bus system) - A connection with the TM-2000 (if communicating via Ethernet) In rare circumstances, communications across one of these links could stall. In this case, the link would normally be torn down and re-established after a few seconds; however, for frame-to-frame links, other intercom activity could prevent that from occurring. (The typical symptom was that AZedit would continually lose contact with the intercom and then immediately reconnect.) * Several alarms made persistent The following alarms should have been persistent, but were not: - Frame mapping tables do not agree: slot , link - System sizes differ: frame , controller - Frame IDs do not agree: slot , link These alarms are now persistent. (The only effect of this change is that unresolved instances of these alarms cannot be cleared; however, they can still be hidden.) New in version 2.6.1 -------------------- * An AZedit session connected to a slave frame can now set the date/time The date and time are used for logging and as UPL conditions. In earlier versions, only an AZedit session connected to frame 1 could set the date and time. Now, an AZedit session connected to a slave frame can set the date and time. For an AZedit session to set the date and time, the following must be set in the Configure Logging dialog: - the AZedit session must be configured as the log destination, and - the "All frames" option must be selected * Fixed trunk testing In versions 2.5.0 and 2.6.0, automated trunk testing (with Trunk Supervisor) would fail, with an indication that the loopback test on the test port had failed. Fixed. * Fixed problem in flash handling It was possible to get a corrupted setup saved in flash. Fixed. This problem would typically occur if the configuration flash was in the middle of being updated because of recent changes, and then a change requiring a reboot was made to the frame mapping table or the port allocation table. Note: The standard version of firmware reports its version as 2.6.0. The build date and checksum can be used to determine the actual version: Version 2.6.0: March 29, 2011, CRC=5b1f Version 2.6.1: May 16, 2011, CRC=be31 The Japanese version of firmware reports its version correctly. New in version 2.6.0 -------------------- * Unavailable trunks automatically taken out of service In a multi-frame system, if 1 or more frames are unavailable (powered off, or not communicating with the primary frame), any trunks which connect to unavailable frames are automatically taken out of service. When communications to a frame is restored, trunks connecting to that frame are restored to service. Taking a trunk out of service is similar to, but independent of, putting it into maintenance mode. The Trunk Master will not try to use a trunk if the trunk is either out of service or in maintenance mode. Trunk Supervisor v1.8.0 or later recognizes trunks that are out of service. Trunks that are out of service are not tested, since the test would almost certainly fail. Taking trunks out of service is only available when the intercom is communicating with the Trunk Master via Ethernet. (This does not include the situation where the intercom is communicating serially using RVON pass-through data.) * Added IFB-SL tallies IFB Special Lists now tally, similarly to IFB tallies. A key with an IFB-SL assignment displays an in-use tally whenever anyone is talking to that IFB-SL, or whenever anyone is interrupting any of the IFBs which are a member of the IFB-SL. A key with an IFB-SL assignment displays a busy tally if the key is on, and either (a) the panel has an IFB priority of 0, which means the panel is not allowed to interrupt IFBs, or (b) another panel, with a higher IFB priority, is talking to the IFB-SL, or (c) another panel, with a higher IFB priority, is interrupting any of the IFBs which are a member of the IFB-SL. * IFB-SL tallies are available across trunking IFB-SL tallies across trunking are handled like IFB tallies across trunking (see the description for this in the list of changes for version 2.5.0). Each IFB-SL has a remote tally enable flag associated with it; this flag must be checked in order for other intercoms to generate in-use and busy tallies for an IFB-SL. * Support keypanels with up to 128 keys The intercom now supports panels with up to 128 keys (e.g. a KP 32 CLD or KP-32 Classic with 3 expansion panels). The default remains at 64 keys per port. The number of keys per port can be set when reconfiguring the intercom, by setting "Keys per port" to 64, 96, or 128 on the Options tab of the Intercom Configuration dialog. In order for a keypanel to support more than 64 keys: - The intercom must be configured for 96 or 128 keys per port - The keypanel must be connected to an I/O card (AIO-8, AIO-16, or RVON) which supports more than 64 keys per port - The keypanel must be running firmware which supports more than 64 keys per port Support for keypanels with more than 64 keys has no impact whatsoever on trunking. An intercom with support for more than 64 keys per port can be trunked with other intercoms that only support 64 keys per port. * Added support for adjusting IFB listen source levels From a keypanel, it is now possible to adjust the listen volume for an IFB with an AT assignment. This adjusts the volume of the crosspoint from the IFB's listen source to the keypanel's listen destination. * Command-Line Protocol enhancements Command Line Protocol supports the following additional commands: - Query and set 6- and 8-character alphas and aliases - Query and set 8-Unicode alphas and aliases (if enabled in the intercom) - Query and set input alphas (all sizes) (if enabled in the intercom) - Query which ports have communicating keypanels (available as a normal status query and as a stored query) - Query and set the date and time - Support setup pages 10 and higher The CLP documentation has been revised to include descriptions of these revisions. * CLP processing speed improved when making changes in large intercoms. In a multi-frame system, if certain changes were made via CLP in one frame, and that frame was currently resynchronizing with another frame (sending its current configuration to the other frame), the CLP changes might not be forwarded to the other frame. Fixed. * Added new UPL condition: Is there a keypanel present on port X? New in version 2.5.0 -------------------- * Added support for IFB tallies across trunking IFB interrupt status (and current interrupt priority) is now forwarded through the Trunk Master to all intercoms. This allows keypanels in intercom X to display the correct IFB status for IFBs in intercom Y (i.e. an in-use tally for an IFB which is being interrupted). To prevent a flood of IFB tally information from being generated, this feature is disabled by default. IFB tallies across trunking must be enabled individually for each IFB, via a new checkbox ("Remote Tallies") in the IFB edit dialog. In order for a keypanel in intercom X to display IFB interrupt status for IFB Z in intercom Y, the following conditions must all be met: - frames X and Y must both support IFB tallies across trunking - the TM-2000 must support IFB tallies across trunking - the "Remote Tallies" box for IFB Z must be checked * Added support for 2 Trunk Masters The intercom can now be connected simultaneously to two independent Trunk Masters (where each independent Trunk Master can be a single stand-alone TM-2000, or an active/standby pair). This is configured via the Options | TM Communications menu item in AZedit. The two Trunk Masters operate independently. The intercom combines the data from both Trunk Masters, e.g. when selecting a remote key assignment, the key assignment grid shows a list of matrix names which combines the matrix names defined by each of the Trunk Masters. An intercom is told its own name by the Trunk Master. If the two Trunk Masters give the intercom different names, the intercom uses the name given it by Trunk Master #1 (as defined in the TM Communications dialog). Each intercom supports up to 31 remote intercoms. If the total number of intercoms defined by the two Trunk Masters exceeds this, one or more remote intercoms will be inaccessible. In this case, TrunkEdit will report the conflict when it detects this condition (and will warn the user if an attempt is made to define too many intercom names). Both AZedit and TrunkEdit will warn the user if both Trunk Masters attempt to define the same intercom port as a trunk port. In this case, each Trunk Master will force the conflicting trunk into maintenance mode. Red LED #18 is lit when the PeriphII-e is communicating with the first Trunk Master (no change). Red LED #17 is lit when the PeriphII-e is communicating with the second Trunk Master. * I/O card error counters can be cleared for frames 2+ In versions 2.3.0 and 2.4.0, clearing the error counters on the I/O card status screen would only clear the errors for cards in frame 1. Fixed. * Clear I/O card type information if I/O card is removed If an I/O card is plugged into a slot for which no timeslots are allocated, the intercom remembers the I/O card type, for convenience when editing the Port Allocation Table. However, if the card was subsequently removed, the I/O card type information was not cleared. Fixed. * Improved automatic updates to the frame mapping table * Fixed AZedit disconnect problem * Fixed processor reset problem See version 2.2.3 for a description of these changes. New in version 2.4.0 -------------------- * Added support for Unicode alphas Unicode alphas were previously only available in Japanese builds. Now, you can enable Unicode alphas as part of the intercom configuration using AZedit V4.0.0. Using Unicode alphas allows alphas to contain characters beyond the basic ASCII, including Cyrillic, Greek, and Latin (most European accented letters). These character sets are supported on keypanels like the KP 32 CLD, KP 12 CLD, KP812-U, and KP-12/4U (Cyrillic). Using Unicode alphas requires compatible AIO card firmware: AIO-8 V10.5.0 and AIO-16 V1.3.0. RVON-8 / RVON-16 firmware already support Unicode alphas. New in version 2.3.0 -------------------- * Added support for a separate CWW key for the KP 32 CLD The KP 32 CLD supports up to 64 talk and 64 listen keys, plus a separate call-waiting window key. In earlier versions, key 16 was the CWW key, and these two keys operated in parallel. Starting with KP 32 CLD v1.2.0, the intercom now supports a separate CWW key, and key 16 is now a regular talk/listen key. Note that the I/O card firmware (and any RVON firmware, if applicable) must be updated to a version that supports a separate CWW key. If any one of the devices (intercom controller, I/O card, or keypanel) does not support a separate CWW key, the system will operate normally, but the KP 32 CLD will operate without a separate CWW key (i.e. key 16 will be the CWW key). * Added full support for MADI-16+ cards Support for 16-channel MADI-16+ cards was added in v2.2.0. This version of firmware adds support for MADI-16+ cards with up to 64 channels of audio. * Added Port Allocation Table The Port Allocation Table controls which ports are allocated to which I/O cards. This is necessary when using MADI-16+ cards with more than 16 channels of audio. * Added support for ADAM-M frames * Resizing the intercom now provides information about remote alpha pool usage On the intercom reconfiguration dialog, when the Test button is pressed, information is now returned about the pool of memory used for remote alpha storage, including both the current usage and what the usage would be with the revised configuration. New in version 2.2.3 -------------------- * Improved automatic updates to the frame mapping table Some updates to the frame mapping table happen automatically (e.g. if you swap out the standby controller in a frame, the frame mapping table in all frames should be updated to reflect the IP address and MAC address of the replacement card). These changes were not always being forwarded to all frames. Fixed. * Fixed AZedit disconnect problem If a transfer of control occurred in a frame, AZedit sessions (connected either to that frame or to other frames) might disconnect and not be able to reconnect for an extended duration. Fixed. * Fixed processor reset problem For very large 4-frame systems, the active controller in frame 1 could reset at times when it was very busy. Fixed. New in version 2.2.2 -------------------- * Fixed handling of remote intercom listening to IFB via AT If a panel on another intercom is listening to an IFB on this intercom 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.