1.0 Introduction

Doors.NET allows you to configure, command and control the SCP Series access control hardware manufactured by Mercury Security Corporation. The SCP controllers are compatible with magnetic stripe and Wiegand output readers such as proximity, bar code, fingerprint, hand geometry and other various readers. Keypads and integrated keypad readers are also available. The controllers can be configured to support 100,000 users each. Up to 65,536 inputs or outputs can be configured per site.

The inputs and outputs can be configured to door related functions or to general purpose I/O. The inputs support normally-open, normally closed, supervised and non-supervised circuits. (EOL) resistance values are user configurable. The output relays can be configured for fail safe or fail secure operation. The Doors.NET software allows direct control of the inputs and outputs which also allows you to mask and unmask the inputs. Time Schedules can also be associated with control of the outputs. Doors.NET with SCP hardware also allows you to select from 6 different anti-passback modes, 2 person rule, and up to 8 different card formats per System Processor Module (SPM) which can operate simultaneously.

2.0 Hardware Setup Changes (in Doors.NET v5.2.0)

Various hardware setup changes have been made to v5.2.0 of Doors.NET. This is to improve the work flow when setting up Mercury hardware

2.1 Selecting an RS-485 or Network Node

When selecting a RS-485 or network node. Based on controller type, this will display the available serial or network protocols that each controller supports. License check is made when hardware is added.

2.2 Adding a Network Node (Wireless Lock Integration)

There is a slight difference in setting up hubs for wireless locks (for example, Simons Voss or Allegion Gateway Nodes). Prior to v5.2.0, a gateway node would be added to a controller bus. From v5.2.0 and onwards, the gateway node is added to the hardware tree as a Network Device. This change improves the setup workflow of wireless lock integration with NXT-MSC and Mercury controllers. Although a controller is still required for the integration, this change also allows for all of the controller buses to be used for general access control.

2.3 Downstream RS-485 Devices

Downstream hardware is under each TB node instead of directly off the controller. This is now consistent with how the hardware is displayed for NXT and NXT-MSC in the previous Doors.NET version (v5.1). TB names change to reflect the actual name on the MSC controller. The baud rate setting for the downstream devices is also set at the TB/Bus port (instead of on the controller). Each TB port can have a different baud rate setting.

Example:

The figure below shows TB3 and TB4 for a LP2500:

Selecting TB3 will show the configured serial protocol. In this case, the protocol is Schlage RSI which is fixed at 9600 bps. This protocol supports the AD-300, PIM, and ENGAGE products from Schlage (Allegion).

This is the ribbon bar selection when the protocol for Bus/TB is Schlage RSI:

Selecting TB4 will show the configured protocol. In this case, the protocol is Mercury Security.

The baud rate is changeable and applies only to this port.

Expanded views of the LP2500

2.4 Ribbon Bar Icons

The ribbon bar icons now display the icons relative to the protocol enabled on the bus, so selecting a bus/TB or network node will only displays the icons relative to the protocol defined for that bus.

Ribbon bar for NXT-MSC controllers with Keri Protocol:

Ribbon bar for NXT-MSC bus 2 using Mercury Security Protocol

This is the ribbon bar selection when the protocol for Bus/TB is Mercury Security:

Notice the AH30 is displayed. This is because the Aperio AH-30 has MSC firmware that communicates via Mercury Security protocol.

3.0 Address 0

From Doors.NET v5.2 and onwards, the software allows the address 0 on panels that support a changeable address and support that address.

Doors.NET v5.1.0 always started the addressing at 1 with address 0 being used for the internal panel on the controller. With the changes that have been implemented for the Bus/TB ports, the comm address can now start at 0.

Note: some devices like the AH30 have address 0 reserved internally for pairing or other functions.

4.0 Changeable Comm Address

Effective from Doors.NET v5.2.0 and onwards, the comm address and panel number are no longer linked. This means the comm address is only dependent on the bus/TB port and whether the device supports the address range. Devices that have addressable RS-485 addresses are now changeable in the property grid with advanced mode enabled. The drop-down of available addresses are the current address and any addresses not in use by other devices on the same port.

In addition, the UI checks to make sure that only the address range of the device is displayed. An example would be when using an AD-300 or Aperio AH-30.

5.0 Device Capacity

In Doors.NET v5.1.0, the UI limited the number of devices to 32 per controller. With v5.2 and onwards, the 32 device limit is now per port and the total number of devices per controller. For controllers with a single port, there is really no change as the limit is still 32 devices. Summary of increased capacity is noted below:

● EP/LP 1501 - 8 RS-485 devices, 17 reader limit is still as before.

● EP/LP 1502 - 33 devices total, 64 readers, 528 inputs, 528 outputs, this includes the onboard device.

● EP/LP 2500 - 64 devices, 64 readers, 1024 inputs, 1024 outputs.

● NXT-MSC 2D,EP/LP 4502 - 65 devices, 64 readers, 1040 inputs, 1040 outputs, this includes the onboard device.

● NXT-MSC 4D - 96 devices, 64 readers, 1536 inputs, 1536 outputs. , this includes the onboard device. 96 devices is the max allowed by the controller firmware.