_____________________________________________ ADAM MCII-e Master Controller - Version 3.5.2 _____________________________________________ Code image CRC Standard: 7cc2 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 (mesh wiring only) - Redundant multi-frame systems: - 2 to 6 frames (mesh wiring) - 2 to 9 frames (ring wiring) 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 3.5.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 3.4.x or earlier, but will remember the system size. If the MCII-e is upgraded from v2.6.3 or earlier, it will forget any saved system size, and will restart with the default system size (single frame, 272 ports). NOTE: The MCII-e will preserve the frame mapping table when upgrading from an earlier version. However, if the firmware version is downgraded to version 2.7.0 or earlier, the system will lose its frame mapping table; it will restart with a default frame mapping table (the controller will restart as frame 1; the remaining entries of the frame mapping table will be empty; and the frame will not have any links to other frames). AZedit: Requires AZedit v3.6.2 or later. Requires AZedit v5.4.2 or later for support of all features. AIO-16A Card: Requires v1.0.0 or later. Requires v1.3.0 or later for suppression of polling on non-data ports 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. Requires v1.5.0 for support for trunking more than 31 intercoms. Requires v1.7.0 for full support of KP-Series keypanels, including keypanel mirroring, voice messaging, and editing the keypanel configuration. OMI Card: Requires v6.4.0 for support of PAP-5032. RVON+ Card: Requires v1.0.0 or later. 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. Requires v2.4.0 for support for trunking more than 31 intercoms. Requires v2.5.1 for full support of KP-Series keypanels. Requires v2.7.0 for full support of PAP-5032 panels and RVON+32 cards. MADI Card: Requires v1.0.0 or later. Tri-Bus Expander: Requires v1.0.0 or later if configured for mesh wiring. Requires v1.1.0 or later if configured for ring wiring. GPIO-16: Requires v0.0.3 or later. PAP-5032: Requires v1.0.0 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. TM-2000: 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. TM-10K: Requires v10.0.0 for trunking of more than 31 intercoms. 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 3.5.x. If the active controller in one frame is v3.5.x, 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 v3.5.x, 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 Should be open (reserved) 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 3.5.2 -------------------- * Added security features for compliance with California Senate Bill 327 For new devices, authentication must now be configued when first connecting to the device. This is necessary for compliance with California Law, re: SB327: An act to add Title 1.81.26 (commencing with Section 1798.91.04) to Part 4 of Division 3 of the California Civil Code, relating to information privacy. With AZedit v5.4.2 or later, AZedit will display a message notifying the user of this requirement, and prompting them to set up authentication. (Authentication can also be disabled, although this is not recommended.) Until authentication has been configured, the intercom will not allow changes to be made; and AZedit (v5.4.2 or later) will be in View (read-only) mode, where the various edit controls are all disabled, and most edit fields are shown with a pink background. With earlier versions of AZedit, no notification will be displayed, but the intercom will refuse to accept any changes until authentication has been configured (via the Authentication | Configuration menu option). No change needs to be made to existing devices when this version of firmware is downloaded; however, if a subsequent factory reset is performed on the device, it will then enter the state where it requires authentication to be configured. * Fixed handling of PAP-5032's in large systems When connected to a system with a large number of ports and/or IFBs, a PAP-5032 might not receive all of its data at power-up. It would typically show default alphas (e.g. N003, F129) rather than the correct alphas for some of its key assignments. Fixed. New in version 3.5.1 -------------------- * Added support for disabling polling on non-data ports Keypanel polling on a port is disabled if the panel type is set in AZedit to any of the following: - Virtual - SSA-324/424 - SSA-424A / DSI-2008 - Camera Port - Non-Data Port - IFB Port For an AIO-16A card with a MDR back-cards, polling is enabled or disabled individually on each port, based on the configured panel type. For an AIO-16A card with a SCSI back-card, polling is enabled or disabled for a set of 8 ports, based on the configured panel type for the first port in the set (port 1 or port 9 on the card). NOTE: This feature requires AIO-16A version 1.3.0 or later. New in version 3.5.0 -------------------- * Added support for RVON+ cards * Added support for PAP-5032 panels The intercom can be reconfigured to support up to 64 PAP-5032 panels. PAP-5032 panels connect to standard keypanel ports, via AIO, OMNEO, or RVON. The PAP-5032 Mapping Table (available under the Options menu in AZedit) must be edited to define which ports are PAP-5032 ports. The PAP-5032 can be used as a standard PAP (to view and change which Program Inputs feed which IFBs); it can also be used to adjust program source and IFB output levels, and to monitor (listen to) program sources and IFBs. * Allow (standard) key #16 assignment to be changed via Command Line Protocol In earlier versions, the assignments for key #16 could not be changed via CLP. However, this is now allowed for keypanels with a separate call-waiting window (such as the KP-Series keypanels), where key #16 is a standard talk/listen key. New in version 3.4.5 -------------------- * Fixes and improvements for Japanese variant If a special list only had 4-wire ports as members, calling it was not possible - the caller would get an "Off" tally and the talk key would be forced off. Fixed. If two panels were involved in a private group conversation, and then one panel turned off its talk key, the other panel's talk key becomes a page, but it would only generate a 10-second tally, rather than an indefinite tally. Fixed. Using a "," in an auto-dial number would cause the keypanel to ignore the auto-dial number, and instead display the standard TIF dial menu. Fixed. Now a "," inserts a 1-second pause. New in version 3.4.4 -------------------- * Increased available memory for remote alphas in large systems In very large systems (typically 880 ports), depending on the intercom configuration, there may be very little memory available for storing remote alphas. The MC reserves a buffer for downloading new firmware images. With this version of firmware, if the alpha pool size is too small, it will reduce the size of the firmware download buffer. With the reduced download buffer size, it will not be possible to download a new font to the RP-1000; however, other firmware downloads will still be supported. * Defining a new intercom name could lead to a memory corruption in the MC. The memory corruption could possibly lead to the MC resetting. Fixed. This issue would only happen when the intercom name was first defined (or when the MC first started communicating with the TM); if the MC was reset, there wouldn't be any problems when it received a list of intercom names from the TM. * It was possible for a SIP server communications link to always report as out of date ("OK Old"), even when there was no outstanding data to send. Fixed. * For Japanese systems: A keypanel in-use tally (if enabled) would override an indefinite P-P (incoming call) tally. Fixed. Now, indefinite P-P tallies have priority. New in version 3.4.3 -------------------- * Improved update speed when activating changes The time required to activate a set of changes that have been sent to the intercom has been improved significantly. Also, when a third-party control system sends changes to the intercom, it can request that saving the changes to flash be deferred, further improving the response time. (The changes will be saved to flash automatically, within the next 5 minutes or so.) * AZedit alarm generated on flash update failure If an error occurs when trying to update the flash, an AZedit alarm is generated. If errors are occurring on an ongoing basis, the alarm will be regenerated, but no more than once per hour. New in version 3.4.1 -------------------- * Provide alphas to TIF Tally System If an ADAM intercom is used with a VLink SIP Server and a TIF Tally System, alphas are now forwarded through the SIP server to the TIF Tally system, so that the alphas in the TIF Tally system are always up to date. New in version 3.4.0 -------------------- * Added support for AFK and voice messaging A panel can be put in AFK (Away From Keypanel) mode by hitting Shift-AFK (0-2). When a panel is in AFK mode, normal calls to the panel will receive an indication (chime and tally) that the target panel is AFK. The user can leave a voice message by hitting Shift (0) and then turning on a talk key. If the target panel is AFK, and there is an available voice message buffer, the caller can leave a voice message of up to 30 seconds. A count-down timer is displayed on the talk key. The voice message is terminated when the 30-second limit is hit, or if the caller turns off the talk key. Voice messages can be reviewed and played back by hitting Shift-VM (0-8) to access the Voice Messages menu. A message is retained until the panel is reset or the user deletes the message. The Voice Message menu is not accessible unless there is at least 1 recorded voice message. * Added support for keypanel mirroring A new service menu item, "Mirror", allows the user to select a target panel to be controlled. During the mirror operation, the supervisor panel (the one initiating the operation) displays the state of the target panel (key on/off states, key assignments, volume settings, key options, etc.), and the supervisor can update any of these settings. Once the mirror operation is terminated, the target panel maintains the new settings, while the supervisor panel reverts to its configuration (from before the start of the mirror operation). During the mirror operation, all audio to/from the target panel is reproduced at the supervisor's panel. Incoming calls to the supervisor's panel are blocked, and the caller receives a "do not interrupt" (busy) tally. Any KP-Series keypanel running v1.2.0 or later can be mirrored. In order to start a mirror operation (take control of another panel), the controlling panel must have a Control Feature Set license, and the "Enable Keypanel Mirroring" Option must be set for that panel (on the keypanel view, click the Edit button and select the Advanced tab). * Added support for uploading and downloading of keypanel configuration All of the keypanel's local configuration data (key options, mic selection, audio mixing, GPIO assignments, etc.) can be uploaded and downloaded. AZedit can upload the settings, make changes, send the changes, save the keypanel configuration to file, and send saved changes to the keypanel. * AZedit can control various features in real time The following can be adjusted in real time, by right-clicking in the Port Status area on the keypanel configuration screen: - Headset transfer state (*) - Mic mute status (*) - AFK status (*) - Tone generator (*) The following volumes can be adjusted in real time, by clocking on the speaker icon next to the Edit button in the Keypanel / Port Settings area on the keypanel configuration screen: - Crosspoint listen levels - Party line listen levels - Port input and output gains - Speaker and headset output volumes (*) - Matrix Input, OMNEO Input, and Aux Input volumes (*) Note: Items marked with a (*) are licensed features. Real-time control for those items is only enabled if the panel has a valid license. * Added support for Priority Call override of the speaker and headset volumes If Priority Call is enabled for port X, and port X calls port Y, then the minimum speaker and headset volumes for port Y are set to -6dB (i.e. if the headset volume is less than this, it is bumped to -6dB; but if it is greater than this, it is not touched). Port Y's volume settings revert to their previous values when the priorty caller stops talking. * Added new UPL output action: "Hang up TIF" * New alarm: Standby controller became active If the standby controller loses contact with the active controller and becomes active, it generates a new alarm, "Lost contact with other controller, becoming active". Previously, it would only log the message "Lost contact with Standby controller", which was ambiguous. Note: This alarm never clears by itself; it will remain until cleared from AZedit. * New alarm: Standby controller became active briefly If the active controller detects that the standby controller became active briefly, and then reverted to standby, it generates a new alarm, "Standby controller became active briefly". Note: This alarm never clears by itself; it will remain until cleared from AZedit. * Keypanel diagnostic logs can be downloaded from any frame Certain errors will cause a KP-Series keypanel to write a diagnostic log to its flash memory. Starting with MCII-e v3.2.1, this diagnostic log can be uploaded to AZedit and saved to file. However, in v3.2.x and v3.3.x, AZedit had to be connected to the same frame as the keypanel in question. Now, AZedit connected to one frame can upload the diagnostic log from a keypanel connected to a different frame. * Panel might not get a "list empty" message for a local scroll list If a panel with a separate CWW asks for a local scroll list, and that scroll list is completely scroll restricted, the panel would not be sent a "list empty" message if an assignment of that type was programmed on talk key #16 (which is *not* the CWW). Fixed. New in version 3.3.4 -------------------- * Support up to 8 VLink SIP servers (stand-alone or active/backup pairs) SIP support via a VLink server was added in version 3.1.0. This version allows the intercom to communicate with up to 8 independent VLink servers. When configuring ports as SIP lines, the user can select a specific SIP server, and then choose from a list of SIP line names for that server. * Added descriptions for SIP servers Each VLink SIP server can now have a description associated with it. New in version 3.2.3 -------------------- * Fixed handling of remote IFB and IFB-SL tallies In versions 3.2.1 and 3.2.2, if a key has a remote IFB (or remote IFB-SL) assignment, and remote tallies are enabled for that IFB / IFB-SL, the tally was not handled correctly. (It would generate an incoming call tally on non-KP-Series keypanels, and could end up with a stuck in-use tally.) Fixed. * Fixed communications problems in very large systems In very large multi-frame systems (880 ports, and 8 or more setup pages), the intercom could sporadically report a brief loss of communications with the standby controller and/or the Trunk Master. (This would typically occur when sending changes from AZedit.) Fixed. New in version 3.2.2 -------------------- * Improved DHCP Server operation With earlier versions of MCII-e firmware, it was possible for the MCII-e to hand out an IP address in response to a DHCP request, before it had confirmed that no-one was using that address. Now, a lease on an IP address is not granted until the MCII-e has had a chance to test if any device is using that address. * Fixed handling of always-on display of key volumes In version 3.2.1, in multi-frame systems, always-on display of key volumes did not work for panels connected to any frame other than frame 1. Fixed. * Fixed transfer of enhanced tallies between frames In multi-frame systems, when two frames start communicating, the current intercom configuration is transferred from one frame to the other, so that they are both using the same configuration. However, in v3.2.1, enhanced tally definitions were not transferred properly. (If changes were made from AZedit, then the changes would be made correctly in all frames.) Fixed. * Fixed transfer of configuration data to the standby controller In version 3.2.1, some configuration data was not transferred to the standby controller. On a transfer of control, the standby controller could end up with a corrupt configuration. Fixed. New in version 3.2.1 -------------------- * Added support for KP-Series keypanels This includes the KP-4016 (1RU) and KP-5032 (2RU) panels, and the DKP-4016 desktop keypanel. * Added support for configurable text colors Earlier versions supported configurable background colors for key assignments (supported on KP 32 CLD and RP-1000 panel families). This version allows the text colors to be configured as well. (Only supported for KP-Series keypanels.) * Enhanced tallies Various tallies (e.g. incoming call tally; ISO in use; IFB busy; TIF ringing) can now be customized, to control how they are displayed on KP-Series keypanels. In addition, they can be customized for how they are displayed on other keypanels that do not support configurable tallies (e.g. whether a TIF that is off-hook generates a tally or not). NOTE: Trunk in-use tallies are still controlled globally via the configuration option "Don't generate tallies for in-use trunk assignments". If this option is selected, an in-use tally will not be generated simply by turning on a key with a remote assignment (although it might generate an in-use tally, e.g. because the assignment is a remote IFB). If the option is not selected, the type of tally generated for in-use trunk assignments can be controlled via the tally definitions. Tallies for off-hook TIFs, and indefinite party-line tallies, are handled similarly. * Added new UPL actions: Generate tallies A tally can be generated for a specific key on a specific keypanel. It can also be generated for any local key assignment. A duration must be specified for a tally for a specific key; a tally for a key assignment can either be indefinite (until the UPL statement becomes false) or timed. * Added new UPL conditions: Is TIF off-hook? Is TIF phone line ringing? * Added new UPL condition and actions: Mic Mute UPL can test whether a panel's mic is muted. UPL can mute and un-mute a panel's mic. The mic mute status is also displayed in AZedit. * Added new Command-Line Protocol commands and queries: Mic mute status * Added new Stored Queries (Command-Line Protocol) Is TIF off-hook? Is TIF phone line ringing? Is panel in headset transfer? * Added Priority Call Associated with each port is a "Priority Call" flag, along with an associated volume. If this flag is set, then when that port turns on a P-P talk key, the crosspoint volume is bumped to the Priority Call volume for the caller's port (if the crosspoint volume is set to anything lower). * Added support for always-on display of volumes for key assignments This is only supported for KP-Series keypanels. * Alarm generated for excessive keypanel power-ups If a keypanel powers up more than 4 times in a minute, an alarm is generated. The alarm is never automatically resolved, but can be cleared from AZedit. * Improved download support In some cases (e.g. when AZedit is connected via a WAN or VLAN), lost packets could cause a download to fail. Fixed. New in version 3.1.1 -------------------- * Added SIP support The intercom supports dial-in and dial-out via SIP lines, via a VLink server. In this configuration, the intercom communicates with the VLink server, and the VLink server handles the SIP interface. For each SIP line, there is an audio connection from the VLink server to a port on the ADAM intercom. AZedit allows the user to designate that an ADAM intercom port connects to the VLink SIP server, and what the corresponding SIP line is. From a user at a keypanel, the behavior of an intercom port which is a SIP line is identical to the behavior of an intercom port that has a TIF-951 or TIF-2000/TIF-4000 connected. This includes keypanel commands (seize line; dial out; hang up) and phone line status (line ringing; off-hook). New in version 3.0.6 -------------------- * Improved communications with RVON-16 cards Version 3.0.5 addressed RVON-16 communications problems. However, the problems could still occur in small systems with a small number of I/O cards. Fixed. * Fixed spontaneous reset of MCII-e Some MCII-e cards would sporadically reset spontaneously. Fixed. New in version 3.0.5 -------------------- * Fixed occasional loss of communications with RVON-16 cards In a system with RVON-16 cards, the MCII-e could occasionally lose contact with an RVON-16 card, marking it as not communicating; it would then restore communications with the RVON-16 card a few seconds later. Fixed. New in version 3.0.4 -------------------- * Fixed memory corruption problem with enhanced trunking If a connection was defined to a second trunk master (via "Trunk Master Connection #2" in the Options | Trunk Master Communications dialog), the program input for IFB #1 would be deleted whenever communications was established to the second Trunk Master. Fixed. New in version 3.0.3 -------------------- * Fixed handling of intercom groups when connected to TM-2000 In versions 3.0.0 through 3.0.2, the MCII-e did not handle intercom group information correctly when connected to a TM-2000. (There was no issue when connected to a TM-10K.) As a result, keypanels might not be able to access remote scroll lists for certain intercoms. New in version 3.0.2 -------------------- * Improved IFB response time for multi-frame systems In multi-frame systems with large numbers of keypanels connected, IFB response time (from when the talk key is pressed until when the keypanel's audio is present on the IFB output) could be slow when the IFB output was in a different frame than the interrupting keypanel. Fixed. * Stuck CWW audio for multi-frame systems In multi-frame systems, it was possible for keypanel audio to get stuck on, when using the call-waiting window key to talk to a port in a different frame. Fixed. (This problem affected KP-32 keypanels, but not CLD panels.) * MCII-e resets during initialization on very large systems If the system was reconfigured for 880 ports and 13 (or more) setup pages, the MCII-e would continually reset during initialization, making the card unusable. Fixed. * On start-up, corrupted configuration is not discarded When the card is reset or powered up, it searches for a saved setup in configuration flash and loads it. It then performs validity checks on the saved setup. Previously, if any of the validity checks failed, the saved setup would be discarded and the MCII-e would start up with a blank setup. This no longer occurs. Any corruptions are fixed (e.g. crosspoint volumes that are out of range are reset to unity), and then initialization continues with the saved setup. It is conceivable (but highly unlikely) that this could result in a setup that causes the MCII-e to crash. If this happens, reset the MCII-e while holding in both pushbuttons, and keep holding the pushbuttons until all the red LEDs turn off at the end of initialization. This will cause the MCII-e to discard the saved configuration and start with a blank setup. (Holding in both pushbuttons has no effect unless the saved setup file fails one or more of the validation checks.) New in version 3.0.1 -------------------- * Fixed trunk tally problems in multi-frame systems For multi-frame systems, it was possible for panels in slave frames to incorrectly generate "busy" tallies for keys with remote assignments. Fixed. * Fixed UPL problem in J6 systems For Japanese systems only, when communications with a Trunk Master was established, it was possible for UPL statements to execute incorrectly; it was also possible for the controller to reset. Fixed. New in version 3.0.0 -------------------- * Added support for trunking of up to 255 intercoms When used in conjunction with a TM-10K Trunk Master, up to 255 intercoms can be trunked together. * Added support for new keypanel protocol New keypanel protocol is required for full support of intercoms #32 and above. When using new keypanel protocol, firmware download times are cut in half. Existing keypanels are fully supported, although they will not be able to access scroll lists for intercoms 32 and above. * Added new alarm: Alpha pool exhausted If the Trunk Master sends more alphas to the intercom than it can store, an alarm is generated. The number of remote alphas sent to the intercom can be reduced through the use of intercom groups (configured via Trunk Edit). Intercom X only receives the alphas for intercom Y if there is at least one intercom group which has both X and Y as members. * Extended Command-Line Protocol The following commands and queries have been added: UE? - Query which UPL statements are enabled UE { <+/~> }* - Enable / disable UPL statements US? - Query which UPL statements are currently asserted The following stored query has been added, allowing an application to asynchronously monitor the status of a UPL statement: US? New in version 2.9.2 -------------------- * Added support for OMNEO devices The intercom now supports OMNEO devices (OMI-16, OMI-32, OMI-48, and OMI-64 OMNEO Matrix Interface I/O cards; OKI-1 and OKI-2 OMNEO Keypanel Interface cards). Support for OMNEO devices is similar to that for RVON devices; however, OMNEO devices have more configurable options: - device name (used for DNS) - whether to use static IP settings or DHCP - DNS addresses - DNS search domain * Added DHCP server The MCII-e now includes a DHCP server. The active and standby controllers in a given frame act as redundant servers (only the active controller responds to DHCP requests). For a multi-frame system, the controllers in each frame are independent, and DHCP servers can be individually enabled within each frame. Each controller can support up to 8 separate DHCP allocation ranges (in the same or differing networks). For each controller, the total number of IP addresses in all ranges must not exceed 1024. NOTE: At start-up, the MCII-e checks all of the IP addresses in its DHCP table, to see which (if any) are currently in use. If DHCP Relay is being used, the MCII-e must be able to ping any such device that might request a DHCP address. New in version 2.8.1 -------------------- * Added support for ring wiring The Intercom Reconfiguration Wizard in AZedit now allows a multi-frame intercom to be configured for either mesh wiring (supported previously) or ring wiring (new). There is no change in operation when configured for mesh wiring. When configured for ring wiring: - Redundant audio is automatically selected. - Each frame requires exactly 2 Tri-Bus cards (in slots 8 and 9). - The system can be configured for up to 9 frames. - A frame can contain up to 768 local ports, subject to the following limitations: - The intercom is still limited to a maximum of 880 ports. - Let 'MIN' denote the number of ports in the smallest frame (the frame with the fewest number of ports). Then the maximum system size is (768 + 'MIN') ports. - The Tri-Bus cards are wired as follows: - In each frame, one Tri-Bus card must have all of its links wired to one of the Tri-Bus cards in the next-lower-numbered frame; the other Tri-Bus card must have all of its links wired to one of the Tri-Bus cards in the next-higher-numbered frame. - To complete the ring, one of the cards in frame 1 must have all of its links wired to one of the cards in the highest-numbered frame. - In some configurations, only 1 or 2 Tri-Bus links may be necessary between a given pair of frames. (The intercom will generate an alarm if there are too few links between a given pair of frames.) * Changing the color of the null assignment didn't work properly If AZedit was used to change the color of the null assignment, but no other color changes were made, the intercom made the change, but did not forward it to panels. (If a KP 32 CLD was then repowered, it would show the new color.) Fixed. * Performance improvements for large systems Various changes have been made to improve the performance of large systems, especially those with larger numbers of frames. These changes also reduce the instances of AZedit disconnecting, e.g. when a frame is powered off. * Fixed problem in Group Call handling (Japanese systems only) See the description of v2.6.3 for further details. New in version 2.7.0 -------------------- * Added support for Panel Party Lines The PPL (Panel Party Line) assignment provides a way for one keypanel to dynamically create a party line. When panel X turns on a PPL key, it dynamically creates a party line as follows: - Any panel T which X is hearing via a P-P (i.e. T has a P-P talk key for X turned on, or X has a P-P listen key for T turned on) becomes a talker on the PPL - Any panel L which is hearing X via a P-P becomes a listener on the PPL As with standard party lines, a port which is both a talker and a listener on the PPL does not hear itself. The PPL is maintained as long as the PPL key is on. (A port continues to participate in the PPL, even if it stops talking or listening to the keypanel that created the PPL.) If a keypanel has multiple keys with the PPL assignment, whenever any PPL talk key is turned on or off, the PPL is updated, based on the current set of talkers and listeners. Once the panel turns off all its PPL talk keys, the PPL is destroyed. Each keypanel can form a PPL, independent of any PPLs created by any other panels. A port can participate in multiple PPLs (i.e. PPLs created by 2 or more other ports) at once. Limitations: - A PPL can have at most 16 talkers and 16 listeners. If a keypanel is talking / listening to more than 16 other ports, only the first 16 become members of the PPL. (Ports that are PPL talkers are given priority as listeners. In other words, if port X is a PPL talker, and the creator of the PPL is also talking to X, then X is guaranteed to become a PPL listener.) - At most 10 PPLs can be active simultaneously. If 10 PPLs are active, and another panel tries to create a PPL, that panel will get a "busy" tally. If a PPL becomes available, it will automatically be used to satisfy an outstanding PPL request, if any. - PPLI (Panel Party Line Inhibit) is not supported. (PPLI is similar to PPL; however, in addition to creating the PPL, any crosspoint from a port that is not a member of the PPL to a port that is a member of the PPL is inhibited.) - The creator of a PPL is never a talker or listener on the PPL, even if it has a P-P crosspoint to itself. - A trunk port is not allowed to participate in a PPL. * Fixed possible UPL problem in slave frames In a multi-frame Tri-Bus system, it was possible for a slave frame to ignore some or all UPL statements. Fixed. The problem would occur at system start-up or after a transfer of control. A newly-defined UPL statement would always work; however, it might stop working on a transfer of control in the slave frame. A UPL statement could be affected if it involved a condition that can only be tested in the affected frame (e.g. crosspoint closed; vox audio present) or an action that can only be executed in the affected frame (e.g. close crosspoint; set headset transfer state). New in version 2.6.3 -------------------- * Fixed problem in Group Call handling (Japanese systems only) If the "Merge Callers" option is not set, it was possible to get incorrect crosspoints (spurious audio, or no audio) for Group Calls. Fixed. (This problem also exists in v2.7.0.) * Changing the color of the null assignment didn't work properly If AZedit was used to change the color of the null assignment, but no other color changes were made, the intercom made the change, but did not forward it to panels. (If a KP 32 CLD was then repowered, it would show the new color.) Fixed. (This problem also exists in v2.7.0.) 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.