Getting Modbus TCP/IP Working With ProSoft Bridges
Most people don't realize that ProSoft doesn't actually run Modbus TCP/IP natively on their devices. What they're really getting is a gateway — a bridge that translates between protocols. The MVI56-MBP series modules, for example, sit in a ControlLogix backplane and handle the conversion from EtherNet/IP or DF1 to Modbus TCP. You configure the module's internal mapping table, set the IP address, and then you're talking to your slave devices. It works fine until you hit one of the edge cases that the manual doesn't mention. Modbus TCP/IP is straightforward on paper. It's just Modbus frames wrapped in TCP packets, running on port 502. The ProSoft angle is that these modules give you a way to talk Modbus TCP to devices that your PLC doesn't natively understand, or to bridge between your ControlLogix system and equipment that only speaks Modbus. The MVI69 and MVI56 families are the most common. They support both master and slave roles, which means a single module can poll multiple slave devices and write results directly into your PLC's memory map. Here's what nobody tells you upfront: the module's scan rate is not the same as your PLC's scan rate. The MVI56-MBP runs on its own internal clock cycle, and it typically polls each addressed register at somewhere between 50 and 200 milliseconds depending on how many points you've mapped. If you have a fast-responding device that your process actually needs to track in real time, the polling gap will bite you. I learned this on a water treatment job where a pH transmitter was updating every 100 milliseconds, but the ProSoft module was scanning at roughly 150. The controller saw lagging data and tripped alarms that weren't actually tripping on the device side. I ended up splitting the mapping across two module instances and staggering the scan intervals, which cut the effective lag to about 75 milliseconds. That was acceptable for the application.
The configuration itself is done through ProSoft's SoftNET software or through a web-based interface on the module. You define your mappings as input or output tables, assign IP addresses for each slave, and set the function codes — reading holding registers, writing single registers, reading discrete inputs. The module handles the CRC computation and retransmission logic internally. You don't touch those details in normal operation. One thing that trips people up is the difference between the module's reported status and what's actually happening on the network. The green link LED being solid doesn't mean communication is good. It only means the Ethernet link is up. You need to check the module's status word in the PLC program to see if each individual slave connection is healthy. I've spent hours chasing what I thought was a module fault only to find that one specific slave device had dropped off the network due to a bad cable. The module kept retrying silently. Setting up a fault timeout and alarm on each mapped slave in your PLC logic is absolutely necessary if you want to catch these problems early. For the actual setup, you'll need the module's firmware and the configuration tool. ProSoft's website hosts the downloads, though you'll need a registered account. The current firmware versions for the MVI56-MBP series are in the 4.x range as of the last update I saw. Make sure you're matching the firmware to your exact module revision number — the P/N on the front panel matters, not just the product name. Older revisions sometimes have bugs in the TCP stack that cause connection drops under heavy load.
I ran into another issue on a project last year where the Modbus TCP slave devices were spread across a subnet that had significant broadcast traffic. The ProSoft module started dropping connections intermittently, but only during peak network hours. The workaround was to enable IGMP snooping on the managed switch and create a dedicated VLAN for the Modbus traffic. Once I separated that traffic from the plant-wide broadcast domain, the connection stability improved dramatically. This isn't something the documentation emphasizes enough — network topology matters just as much as the module configuration. The mapping table is where most configuration errors happen. Each mapping entry consumes a slot in the module's limited memory. The MVI56-MBP can handle around 100 simultaneous mappings depending on the mix of read and write operations. If you need more points than that, you'll need to use multiple modules or look at a different protocol bridge. I once tried to map 200+ registers into a single module and the thing would reset every few hours under the load. Splitting it across two modules solved the problem immediately. There's also a quirk with how the module handles timeout values. The default timeout is set fairly conservatively at around 5 seconds, which is fine for most industrial devices. But if you're communicating with a device that occasionally takes longer to respond — like a variable frequency drive doing a ramp-up — you might need to adjust the timeout per-slave. The configuration tool lets you set individual timeouts rather than using a global value. Again, this detail is buried in the manual and easy to miss.
Get the Full Details
If you need a starting point for configuration, ProSoft provides example projects for Common Practice and for direct SoftNET configuration. The download page is at prosoft-technology.com and you can find the firmware and software under the support section for your specific module part number. Make sure you grab the latest version of the configuration utility as well — older versions have known issues with IPv6 address handling even though you're probably running IPv4 exclusively. The main limitation worth noting is that ProSoft's Modbus TCP implementation doesn't support Modbus TCP security extensions or TLS encryption. If your network requires encrypted Modbus communication, this hardware won't meet that requirement. There are third-party gateways that handle TLS-wrapped Modbus, but they add cost and complexity. For standard plant floor deployments where the network is already segmented and secured at the switch level, the lack of encryption is rarely a practical problem.
