converting mbplus network to TCP/IP


Thread Starter


Can anyone help with some info as to how converting from my 1M MBPLUS network to ethernet. I would also like to know if this conversion is stable and noise immune??
Modicon sold a converter box for this in the past - the 174CEV20030 Modbus Plus to Ethernet Bridge. I don't know if it is still available. It was really just a PC with both MB+ and Ethernet.

A better idea might be to add an inexpensive controller with both MB+ and Ethernet (Modbus TCP) ports on it. Use that controller to transfer data between the networks.


Karl Hunsley


In the past I have used both MB+ and Ethernet, although I cant say that I have converted from one to the other.

However I have found Ethernet to be very stable in operation, and its noise immunity has always impressed me, as I have seen shielded Ethernet cable run side by side with 3 phase power cables with no problems at all.

Although there are industrialised switches and hubs out there I have never used those. Personally I dont like mixing Ethernet gear with control equiment. I have always flood wired the plant floor with Shielded (Foil and Braid)Etherenet cable from a central comms room.

The star topology of Ethernet makes it MORE reliable than MB+ ever was, I have lost count the number of times I have had to strip down an entire MB+ network to find a faulty tap/connection. With Ethernet you simply disconnect a device from the hub/switch and see if the problem goes away.

Ethernet is always easier to sell to IT people than MB+, and can be installed by just about any reputable network installer, try that with MB+.

If absolute reliability is important get your Ethernet cables TDR'ed after they are installed, this should mean that any fault connection is found sooner rather than later.

Use switches rather than hubs these will provide better throughput under load and help stop the propogation of data from a problem/porely configured device.

In an electrically noisy environment limit your Ehternet runs to about 70m to avoid problems. Other than that keep them to about 90m to allow for a patch cable at both ends.

Do not mix your IT network with your control network. Keep them apart at all costs, IT people dont care to much about response times of there networks, well not to the same degree any way. So allowing IT people to use your network is just asking for trouble. If you need to get data from plant devices, then put a good router between the control network and the office network and use the router config to limit the type and amount of traffic that is allowed to migrate between the two networks.

Ethernet is not deterministic at all, so if you need a deterministic response think long and hard about using ethernet.

Always use good quality gear, you can get very cheap Ethernet gear but you get what you pay for, I have always used Cisco gear its exspensive but it just keeps on going. I have seen cheaper gear fail within weeks of installation.

Anyway I hope the above pearls of wisdom help, Ethernet is very good, and can be used for industrial uses, but determinism is not its strong point.

Best of luck

Karl Hunsley
Mission Critical Software Ltd.

James Ingraham

> Can anyone help with some info as to how
> converting from my 1M MBPLUS network to
> ethernet. <

Sure. Remove all Modbus Plus devices. Insert Modbus/TCP devices. You're done! Okay, so you spent a bloody fortune, have a ton of IP addresses to set, and nothing works because you have to change all the configurations to point to an IP address instead of a Modbus Plus node. Oh, and you can't daisy chain, you have to use a star topology. With switches. And can't have more than 3 switches between any two nodes that have to talk. And can't have more than 100m between any two devices. All to have a 10ms update rate instead of a 50ms update rate. Maybe.

If I were building a new installation, I would of course use Modbus/TCP over Modbus Plus. On an existing sytem, though, I'd really need to see some reason to do it. For programming and HMI stuff, I would start slow; add a Modbus/TCP module to a processor or two. A wholesale change-over is extremely expensive, not to mention the chance that you'll never get things working again.

Of course, if you've got a very small network (two or three devices) it's no big deal.

>I would also like to know if this conversion is
>stable and noise immune?? <

Immune? No. But not terrible, especially if you're running the cable in conduit isolated from really noisy stuff like motor cables. You can use shielded twisted pair, but costs go up. You can use fiber-optic, but then costs REALLY go up. We've got plenty of Ethernet on the factory floor with no problems; we've also run into problems that involved re-running cable in new conduit or switching to fiber.

Stable? Usually. Except when it's not. And then nobody can figure out why, so you buy a $4,000 network troubleshooting tool, only to find out some idiot connected a PC with a printer driver that's going crazy.

-James Ingraham
Sage Automation, Inc.

Most of what you say is good advice, BUT you do provide one piece of mis-information: full duplex switched Ethernet that you recommend is FULLY DETERMINISTIC. I have been saying this since 1997 on this forum and all of my ARC reports. I fully discuss this in my book Automation Network Selection (see link below), but since you seem to not know this, I will briefly review the reason.

Original Ethernet as specified by Xerox and in IEEE 802.3 resolves bus mastership by using collision detection. The idea was that a lightly loaded fast network operates at great efficiency if a node first listens for traffic, then hearing none, simply sends its data packet to the destination. While sending, it continues to listen. If another node had simultaneously done the same thing and also began sending, the data frames will collide causing garbage on the network. A collision will then be detected. Ethernet protocol demands that both nodes stop sending and back-off for a RANDOM period of time, before trying again. Presumably, the randomness will allow one node to successfully begin before the other, and that message will be delivered. The randomness of recovery from collision makes collision detecting Ethernet NON-DETERMINISTIC.

Modern Ethernet is full duplex with switches. The switch logic eliminates all traffic not directed to the Ethernet address connected to the switch port. Full duplex operation allows the switch to buffer traffic that otherwise would cause a collision. These effectively eliminate all collisions. Without collisions, there is never a statistical back-off. Without the back-off, there can never be a delay for longer than the switching time of the switch's backplane - a known measure. With no random
delays, full duplex switched Ethernet is fully DETERMINISTIC - by definition.

Dick Caro
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Buy my books: Automation Network Selection
Wireless Networks for Industrial Automation
If all you're trying to do is get your MB Plus network on to an Ethernet network, you might try

They have a MB Plus to Modbus TCP/IP protocol gateway. This allows you to keep your existing network and add Modbus TCP/IP connectivity at the same time.

Hope this helps.

Lynn at alist

Just one warning - I have heard that MBPlus includes a limit of 4 'active connections' per node. This means if you have say 20 PLC and put in a single ENet-to-MBPlus gateway, and an OPC server or DCS/SCADA attempts to rapidly poll all 20 PLC the MBPlus node in the gateway will always be "thrashing" connections (opening, using, closing, reopening). So it will perform much slower than you expect when you connect a 100Mbps Ethernet to a 1Mbps MBPlus.

So consider:

1) using 1 gateway per 4 PLC
- or -
2) Adding MB/TCP to MB/RTU bridges to access each PLC directly one-to-one and leave the MBPlus alone. My company (and many others) product such bridges and you'll likely find that 4 serial bridges costs about the same as 1 Enet-to-MBPlus bridge.

I know of a number of large process plants taking approach #2 exactly because they consider the OPC Enet-to-MBPlus traffic 2nd class and running it thru 9600 baud serial links at each PLC has NO impact on the MBPlus traffic. So they reserve the MBPlus for PLC-to-PLC interlocks and let the OPC work as hard as it can thru this separate channel.

- LynnL,