Technical Specifications

FAQ

1. What is the main function of the Bently Nevada 3500/91-01-02-02?

The 3500/91-01-02-02 is an EGD Communication Gateway Module used with the Bently Nevada 3500 machinery monitoring system. Its main purpose is to provide an Ethernet-based communication path between the 3500 monitoring rack and a compatible external control or monitoring system. The module allows machinery-related measurements, channel information, status information, and setpoints to be exchanged through the EGD protocol. This makes it possible to integrate machinery monitoring information into a plant PLC, DCS, SCADA, or other compatible control platform without requiring every individual monitoring value to be transmitted through separate hardwired signals.

2. Which communication protocols are supported by the 3500/91-01-02-02?

The 3500/91-01-02-02 supports Ethernet Global Data (EGD) Version 2.01 and Ethernet UDP/IP communication. Its Ethernet interface supports 10 Mbps and 100 Mbps communication and follows IEEE 802.3 and IEEE 802.3u standards. This configuration uses a 100BASE-FX I/O module with an MT-RJ fiber-optic interface. When connecting the gateway to an existing industrial network, the external controller should support the required EGD communication method. Network configuration, controller settings, data exchange parameters, and communication mapping should all be verified before commissioning.

3. What data can the 3500/91-01-02-02 transmit to a PLC or DCS?

The gateway can transmit several categories of information generated by the 3500 machinery monitoring system. Producer exchanges include rack, module, channel, and data-value status information, as well as floating-point data values and floating-point setpoints. This allows a PLC or DCS to obtain monitoring information through the Ethernet network and use it for display, process logic, alarm management, or higher-level equipment monitoring. The actual data available depends on the configuration of the 3500 rack and the EGD data mapping. During commissioning, each data point should be verified against the corresponding monitoring channel to ensure that the correct value and status information is being received.

4. Can the 3500/91-01-02-02 receive commands from an external controller?

Yes. In addition to transmitting data, the gateway supports specific consumer exchanges from compatible external control systems. Supported functions include Group Reset, Group Trip Multiply, Group Alarm Inhibit, and Group Special Alarm Inhibit. These functions allow selected control operations to be coordinated between the external controller and the 3500 monitoring system. Because these commands can influence alarm or protection-related functions, they should be carefully evaluated during system design. The PLC or DCS logic should be tested to make sure that commands are issued only under the intended operating conditions and that communication failures cannot result in unintended machinery protection behavior.

5. What should be checked when the 3500/91-01-02-02 does not communicate with the control system?

Troubleshooting should begin with the physical fiber-optic communication path. Since this configuration uses a 100BASE-FX I/O module with an MT-RJ interface, the fiber connection, network equipment, and interface condition should be inspected first. The module’s OK LED should then be checked to confirm that the gateway is operating normally, while the TX/RX LED can help indicate communication activity. After the physical layer has been verified, check the EGD configuration, network parameters, controller settings, and data exchange mapping. The firmware version of the associated 3500/22M TDI should also be checked for compatibility. If the module operates normally but the controller still receives no data, particular attention should be given to the EGD configuration and controller-side data mapping.

6. What firmware requirements apply to the 3500/91-01-02-02?

The associated 3500/22M Transient Data Interface should have Version 1.20 or higher firmware for the EGD gateway application. When consumer exchange functionality is used with compatible 4-Channel modules, Version 2.21 or higher firmware is required. Firmware compatibility should be checked before installing a replacement gateway, especially when integrating the module into an older 3500 monitoring system. After installation, the module status, rack communication, EGD data exchange, and external controller data should be tested. This helps ensure that the gateway and the existing 3500 system can exchange the required information correctly before the machinery monitoring system is returned to normal service.

7. How many 3500/91 EGD Communication Gateway Modules can be installed in one 3500 rack?

A maximum of one 3500/91 EGD Communication Gateway Module can be installed in a single 3500 rack. The main gateway module requires one full-height slot at the front of the rack, while the associated I/O module occupies one full-height slot at the rear. This installation requirement should be considered when planning a new monitoring system or replacing an existing communication module. The available rack positions should be checked before installation, and the main module and corresponding I/O module should be correctly matched. Communication requirements should also be planned around the single-gateway limitation when designing the overall monitoring architecture.

8. What is the purpose of the 3500/91-01-02-02 in an industrial machinery monitoring system?

The module provides a practical communication link between the 3500 machinery protection system and a plant-level automation system. Instead of relying entirely on individual hardwired signals, the gateway can transfer multiple monitoring values and status conditions through an Ethernet communication network. This is useful for applications where machinery condition information needs to be displayed in a DCS or SCADA system, incorporated into PLC logic, or combined with other plant process information. Proper configuration is important because the external system must correctly interpret the transmitted values and statuses. For critical machinery, the communication interface should be treated as part of the overall monitoring architecture, with appropriate testing of normal data exchange, alarm conditions, communication loss, and recovery behavior before the system is placed into continuous operation.