Introduction
Because the Mx-1 controller can be operated in ambient temperatures of 0 degrees Centigrade (32 degrees Fahrenheit) to 60 degrees Centigrade (140 degrees Fahrenheit) with a maximum relative humidity of 90%, an environmentally managed room is usually not required. The controller is typically installed indoors, within the protected premises. Overall, the setup and installation of an Mx-1-ME controller is similar to that of an Mx controller. For details, see the following sections:
The Mx-1 model has a compact plastic case, and can be powered by either PoE+ (providing a nominal 25.5 Watts) or 24V - 28VDC power from an external power supply. Its light weight provides more flexibility when deciding where to install it.
Note that:
An Mx-1 or Mx-1-ME controller has built-in SNIB3 capability which must be configured using DIP switches. For information about setting those DIP switches, refer to “Configuring the Built-In SNIB3”.
An Mx-1-ME controller has small status LEDs which are located in the center of the main board, as shown in Figure 3-2 in section “Mx-1 Controller Main Board”. (A new set of large LEDs is provided on the Mx-1 controller’s main board; see “Status LEDs on the Mx-1”).
The functionality of the Command and Control Module (CCMx) is built into the Mx-1 or Mx-1-ME controller’s main board (instead of being on a separate removable module).
Wiring Distance Limits
The following table shows the wiring distance limits between the Mx-1 controller and various components, which is important information when you are designing a security system for a large facility.
Table 3-14: Maximum Current Draws for an Mx-1 Controller’s Reader Terminals
Type of Wired Connection | Maximum Distance |
|---|---|
RS-485 data only (between two controllers, or between a controller and an OSDP reader) using 22 gauge wires | 4,000 feet (1,220 meters) (tested under lab conditions) |
Wiegand protocol using 18 gauge wires | 500 feet (150 meters) |
Note that the wires must be stranded and pair twisted, with an overall shield.
Configuring the Built-In SNIB3
An Mx-1 controller has built-in SNIB3 capability, with a 5-wire RS-485 Controller Bus terminal that enables multi-drop or long hardwired serial connections, and an Ethernet/PoE+ connector for communication between the Velocity host and the master controller.
For information about SNIB3 functionality, see “SNIB3” and “Benefits of the SNIB3”.
To install a set of controllers connected using SNIB3s or built-in SNIB3 capability, perform the following procedure:
Run the required network cable to the controller(s) with the master SNIB3s.
The Category 6 Ethernet cable you are connecting to each master SNIB3 should be connected to the Velocity host through a hub or switch.
2. Run RS-485 cable downstream from the master SNIB3.
The run between the master SNIB3 and the second SNIB3 must be wired according to the instructions in “RS-485 Cabling for SNIB3s”.
3. Set the DIP switches on each SNIB3, which vary depending on whether it is the master, one in the middle, or the last one. On an Mx-1 controller, be sure to also set its SNIB3 address using the rotary switch.
For details, see “DIP Switches on an Mx-1 Controller”.
4. Plug the end of the Category 6 cable into the Ethernet/PoE+ connector on the Mx-1 controller.
5. Connect the RS-485 cables to their respective SNIB3.
6. Reconnect and power up the controllers.
7. At the host, open Velocity and configure the new SNIB3s.
For more information about the SNIB3, refer to “Installing and Configuring the SNIB3”.
DIP Switches on an Mx-1 Controller
A SNIB3 expansion board includes three DIP switch banks. The first bank (SW1) and second bank (SW2) have four DIP switches each. The third bank (SW3) has eight DIP switches. The location of the three banks of DIP switches on a SNIB3 expansion board is shown in Figure 1-26, “Main Components of the SNIB3 Board”, in section “SNIB3”.
Things are somewhat different for the built-in SNIB3 capability of an Mx-1 controller.
The bank of four switches on the left side of the Mx-1 controller, which is marked Bus Termination on the top cover of the plastic casing, corresponds to the SW1 bank on the SNIB3.
The second bank of switches on the right side of the front of the Mx-1 controller has six DIP switches, which correspond to the SNIB3’s four-switch SW2 and the first two switches of its SW3. The labeling which appears on the top cover of the plastic casing for this bank of switches is shown in the following image:
While the SNIB3 required you to set its address using the last six DIP switches of its SW3, the address of the Mx-1 controller’s built-in SNIB3 is more easily set using the Controller Address 16-position rotary switch, located on the left side of the Mx-1 controller. An Mx-1 controller can only be addressed between 1 and 15.
Bus Termination (SW1)
With their built-in SNIB3 capability, Mx-1 controllers can be used throughout an RS-485 multidrop run; however, you must specify whether a specific Mx-1 controller is at the beginning, middle, or end of a run.
To do this, set all four DIP switches on the Bus Termination switch bank to either all ON or all OFF, with this meaning:
S1 - S4 | OFF | This Mx-1 controller is in the middle of a multidrop sequence. |
|---|---|---|
ON | This Mx-1 controller is either the first (master) or last (termination) one in the multidrop sequence. |
Key Reset / Network Reset / Bus Polling / Bus Baud (SW2)
The second switch bank on the Mx-1 controller has six DIP switches, where S1 configures encryption properties, S4 configures the Mx-1 controller’s location in the multidrop run, and S5 and S6 specify the built-in SNIB3’s communications speed. (S2 and S3 are used to reset a SNIB3 to its factory default settings.)
S1 | OFF | The Mx-1 controller’s built-in SNIB3 communicates with the host PC using the encryption keys stored in memory. |
|---|---|---|
ON | Return the encryption keys to their default settings. If this switch is set ON, when the Mx-1 controller’s built-in SNIB3 powers up or reboots after a firmware upgrade, the keys will reset. | |
S2 - S3 | OFF | Normal operation. |
ON | These switches should only be ON when resetting this built-in SNIB3 to the factory default settings; see “Resetting a Mx-1 to its Factory Default Values”. | |
S4 | OFF | Indicates this controller is NOT first in the multidrop sequence. |
ON | Indicates this controller is first (master) in the sequence, and is connected to the host via Ethernet. This controller’ built-in SNIB3 controls polling. | |
S5 - S6 | These switches specify the built-in SNIB3’s communications speed.
|
57,600 and 115,200 bps are only available if your RS-485 cables are made from Cat5/Cat6 data grade wire. These speeds are not recommended for installations using:
18 to 22-gauge shielded twisted-pair cable
NET*MUX4s
Baud rates only apply to the RS-485 ports for SNIB2s and SNIB3s. All SNIB2s and SNIB3s in an RS-485 multi-drop chain must be set to the same baud rate.
The address of the Mx-1 controller’s built-in SNIB3 is set using the Controller Address 16-position rotary switch.
The Mx-1 controller’s Ethernet/PoE+ port is used for host-to-controller connections and runs at 10/100/1G BaseT speeds. (Because the Mx-1-ME model includes a power supply, its Ethernet connection does not include the Power over Ethernet functionality which is included on the standard Mx-1 model.)
Resetting Mx-1 to Factory Default Values
To factory reset, the Mx-1 controller, follow these steps:
Locate the S1 to S4 switches in the second switch bank of the Mx-1 controller. Please make sure they are in the ON position.
Ensure that the S5 and S6 switches are in the OFF position.
Set the address setter to zero.
Power ON or power cycle controller, depending on the current power state.
Wait for the controller to boot up; the clockwise LED blink of "Host" and "Bus" LEDs stops.
Set the DIP switches back to the original state.
Power cycle the Mx-1 controller one more time.
The Mx-1 controller will now be reset to its factory values, meaning all their network settings and configurations will be reverted to their original defaults.
Network Configuration Options for the Built-In SNIB3
Most controllers can be networked together and managed by a host computer running Velocity, if they use an optional SNIB2 or SNIB3 expansion board. For details, see “SNIB3 Network Configuration Options”.
An Mx-1 controller can be included in that network. The primary difference is that an Mx-1 controller does not require a SNIB3 expansion board, because the Ethernet connector and the RS-485 Controller Bus terminal are integrated onto the controller’s main board, as shown in Figure 3-2 in section “Mx-1 Controller Main Board”.
Deploying the Built-In SNIB3
Each master SNIB3 (Velocity port) must be assigned a unique IP address so it can communicate with the Velocity Server. Depending on the network location of the master SNIB3, this is accomplished in one of two ways:
If the SNIB3 is located within the same subnet as the host PC, then you can use Velocity to assign the IP address. For more about this, refer to “Using Velocity to Configure a SNIB3 on the Same Subnet”.
If the master SNIB3 is located outside the host PC’s subnet, you must use the SNIB Configuration Utility. For more about this, refer to “Configuring a SNIB3 on a Different Subnet”.
What is a subnet? Put simply, it is any group of PCs and other devices, such as printers and scanners, connected by network cable to a network router. Anything behind the router is considered part of the subnet. Anything beyond this router is not part of the subnet.
In the preceding illustration, the master SNIB3 on the Mx controller labeled 1 is located in the same subnet as the host PC (Subnet A). This SNIB3 can therefore be configured using Velocity; however, the master SNIB3 on the Mx controller labeled 2 is located behind a different router, in a different subnet (Subnet B), and must be configured using the SNIB Configuration Utility.
Any number of computers and devices can be behind a single router, but for reasons of security and speed, a company network often incorporates many routers. It isn’t uncommon to find that each department within a company has its own router. Routers not only find the quickest way to ferry packets of information between two points, but also could serve as a rudimentary firewall against potential intrusion.