Honeywell® Mercury SRBX Polling

The Mercury protocol module is capable of handling report by exception call-ins from field devices. 

MI Modem

When an alarm occurs in the Mercury modem, the modem will call the host computer.

After detecting the call-in, ACM will:

1. Accept the phone call (if the host modem is configured to Auto Answer).
2. Request the Mercury device to identify itself.
3. Clear the alarm.
4. Poll for items and historical data.

The detection of a call-in is a two-step process. After the call-in is detected, ACM must identify the Mercury device that initiated the call by sending a poll request. 

Since a MI modem does not identify itself upon call in, ACM must query the modem to know which Mercury device object should handle the unsolicited request. This requires the creation of a "Dummy" Mercury object that will handle all MI modem call-ins and route the request to the correct Mercury object. Only one Dummy object is required per Modem port object to handle all MI modem call-ins.

This dummy Mercury device will have to:

1. Contain “DummyCallin” as its name, or part of its name.
2. Have MI modem option checked on device page.
3. Have Perform demand poll during a call-in option checked on device option page.
4. Have a unique site ID 1 and site ID 2.
5. Have a unique modem port ID.
6. Have an item advised as noted above.
7. Have the Enable Unsolicited Support option checked on Connection tab.
8. Have a polling interval set to 00:00:00.000.
9. Have a port object selected on the connection page.

Messenger Modem

When an alarm occurs in the Mercury device, the Messenger modem will call the host computer and identify itself.
After detecting the call-in, ACM will:

1. Accept the call and identify the device based on the site ID 1, site ID 2, and the device type in the call-in message. All three fields must match the device's ACM configuration.
2. Clear the alarm.
3. Log on to the device.
4. Poll for items and historical data if so configured.

No special configuration is needed other than what is listed in the notes at the top of this article.

TCP Listen Network Connection / CloudLink Modem

If the field device is connected to a terminal server or a CloudLink modem such that ACM is using a TCP Listen connection object to communicate, you will need to:

1. Determine an open TCP port to use for call in.
2. Set a firewall rule to allow incoming connections to this port.
3. Enable a Listen Port on the TCP/Listen object and set the port number to the TCP port that will be used for the call-in.
4. Configure the field device's Call-In Number to be the IP address of the ACM server and the port number chosen above. Enter the values in the format nnn.nnn.nnn.nnn/port, where 'n' is the IP address, a separating forward slash, then the port number.
5. On the field device, configure item 405, Site ID Delay Time, to a value of less than 5 seconds. The TCP/Listen object only waits 5 seconds for initial data after an incoming TCP connection is established so the RTU must transmit before this timer expires.

Processing of a call-in is the same as with the Messenger modem.

See also TCP/IP Cryouts.

TCP/IP Network Connection / CloudLink modem

If the field device is connected to a terminal server or a CloudLink modem such that ACM is using a TCP/IP connection object to communicate, RBX call-ins can still be handled.

You will need to:

1. Create a unique TCPIP Port object for each field device.
2. Set the Connection Type property to TCP.
3. Enter the field device's connection parameters in the Host Address and Port properties.
4. Set the Port Control property to Maintain Control.
5. Advise at least one OPC register item in your client application, or alias list, and poll it at least once to establish the TCP connection.
6. On the field device, set item 486, Modem AT Call (Command) Enable, to "Always Connected No Dial" or "No", depending upon model.

Processing of a call-in is the same as with the Messenger modem.