How prevalent is TCP/IP communication in the industry?

F

Thread Starter

Fuzzy Logic

Hi,

I'm a younger engineer that has been to only a handful of sites and I'm curious about where technology is progressing. For the most part everyone seems to still be using Modbus-type serial communications however I know there are a few vendors (Omega, Seimens) that offer Ethernet TCP/IP products for data communication.

How is your site setup? Does anyone have a configuration where they can buy an off the shelf TCP/IP product that communicates with a standard windows/linux PC on the Intranet or is that something foreign to our industry?

I was looking at the Omega CNi series and it says their products have an optional web server. What would I actually use this for?
 
C

Curt Wuollet

You don't have to look very hard, many vendors can do Modbus/TCP. Often you have to ask as they would rather you use their far more profitable proprietary networks/protocols. But The AB Micrologix has a webserver that you can access with any browser and Automation Direct and Opto22 have IO that works with Modbus TCP. You really have to hand it to the drive and instrument people, They have supported Modbus/TCP and that has pushed more adoption amongst PLC manufacturers. On the PC side there are many closed (for Windows) and open source (for both windows and Linux) implementations available. And modbus.org has example code. I think it would be fair to say it's far more popular than many vendors would like. It's hard to sell against free and Open.

Regards
cww
 
W

William Sturm

I have seem Modbus/TCP far more than Modbus serial in recent years.  Modbus/TCP and A-B Ethernet/IP seem to be everywhere in new systems these days.

A web server in a temperature loop controller would be useful if you would like to monitor the temperature or other parameters from a web browser.

Bill
 
K

Ken Emmons Jr.

Many instrument and control device manufacturers (drives, panel meters, laser micrometers, etc) historically have had a simple command interface over RS-232. In some cases I have seen some manufacturers implement this command interface over Ethernet which is essentially a Berkely Sockets interface where the device is the server and the PC or PLC is the client (sometimes this is configurable). I have set up Epson robot controllers and cognex insight cameras to talk to each other over Ethernet.

Sockets are not to be confused with other interfaces such as Ethernet/IP, EtherCat, Profinet (some of which cannot be plugged into traditional Ethernet networks but must be kept separate from your LAN).

I don't know about the Omega CNi series, but many manufacturers provide a web interface for basic monitoring or setup (much like the web interface on your wireless router at home). This is nice because you don't need to install yet another software app on your PC that will potentially go out of compatability with the new windows OS in 10-15 years.

KEJR
 
L

Lynn August Linse

Adding to what Curt mentioned, I think the bulk of small companies find Modbus support FAR MORE PROFITABLE than proprietary, because otherwise before every sale, customers have to figure in the cost to write new code. For example, I am active in the solar/renewable space and I am seeing vendor after vendor now dropping old protocols in favor of Modbus. Part of this is they now understand the 'uphill struggle' to sell to new customers if their own protocol is a hurdle, and the other aspect is that the large 'solar leasing' firms who may install 500 to 1000 systems a month (& can negotiate good supply contracts with utilities) generally put Modbus in as a supply requirement.

The only thing Modbus fails to do these days is handle high-speed multicast (think group sharing), where imagine you have 30 motors on a single moving line and have 5 PLC/controllers which all want to know motor speed 50 times a second. With Modbus/TCP you have a large 5 by 30 matrix problem of 150 unicast TCP/IP links. Modbus.org could have solved this, but did not (MB+ solves it, but not Modbus/RTU or TCP).

Of the big automation firms, Omron, Schneider-Electric, and Rockwell all use the ODVA/Ethernet/IP stuff, while GE-IP and Siemens sit in the PROFInet camp.

Still, for simple "read the I/O" a few time a second, it is hard to beat the simplicity of Modbus/TCP. I'd certain START with Modbus and only look for something else when you have special timing/scaling needs.
 
L

Lynn August Linse

Actually, if I view this as the more narrow question of serial-vs-Ethernet, I could paraphrase a conversation I had with one of the Rockwell/AB small-PLC product managers a few Automation Fairs back:

They are using this logic for new products:
1) 'free' is the USB device port defined as 'for config/program use only'. Anyone trying to use as part of daily field comms is violating spec. Special serial cables can be purchased to cover the gray area in between.

2) Nearly 'free' add-on is Ethernet with the standard 1500-volt ground isolation. Most small devices these days are running 32-bit ARM and even with Ethernet MAC, they can be as cheap as $1 each. So the days when an RS-232 port was 'cheap' and Ethernet was 'expensive' due to silicon costs are long gone.

3) for people who want true RS-232/485 ports with sufficient surge/ground isolation to make robust in the field, that is an add-on for 'sufficient cost' for 'sufficient robustness'. Adding an isolated serial port can cost $18 to $30 (cost, not sales price!) Ethernet transformers are actually pretty useful for field robustness (over non-isolated RS-232).

So I'd say the day of RS-232 ports on new products is going away (if not gone).

Yet RS-485 will remain, the reasons I hear from vendors is:
1) the power reqs & heat produced for Ethernet is higher than RS-485 (though I've heard people debate this as truth or old-thinking)

2) distance - if your device is likely 500 feet (several hundred meters) away, Ethernet can span that, but not cheaply.

3) the multi-drop nature. Adding 4 more multi-dropped RS-485 is nearly free, whereas supplying 4 more robust industrial-quality RJ45 Ethernet switch ports can cost more than some small devices :).

So my estimate of the trends would be:
- USB for config
- Ethernet for things routinely used indoors
- RS-485 for high-density or long distances.

- Lynn
 
C

Curt Wuollet

I agree, another reason that RS485 will be around is there is an enormous installed base of RS485, most of which is called anything but, RS485. Quite a few of the "flashy new protocol products" run on top of the humble old serial spec. What surprises me is that so few people know that. But the hardware to support it, by any name, will be a must have for quite a while.

Regards
cww
 
F
This may be crazy talk, but are there sites that implement wireless Ethernet/Modbus? I understand there may be concerns about signal integrity or maybe even security, but surely there's someone out there doing this?

Lynn's comments on running Cat5/6 long distances sparked this.
 
L

Lynn August Linse

>This may be crazy talk, but are there
>sites that implement wireless Ethernet/Modbus?

Thanks for being my straight man :). I purposely avoided that can of worms!

I still work for Digi (Etherios division focused on CRM/salesforce.com stuff), but digi sells A LOT of wireless for use with Modbus.

One of the key problems with wireless is that it is inherently a 'broadcast' medium. So what works for linking 2 or 3 'sites' of Ethernet won't work for 50 local sites. Another problem is that 99% of the large demand for 'wireless Ethernet' with longer ranges than WiFi tend to want live video or have users expecting a WiFi like performance experience! So you are talking 10-25MB throughput and maybe close to $1000 for a radio pair. Never mind that your use of Modbus/TCP would be happy at 9600 baud! You are a minority feature.

What you will find VERY successful is wireless classified as 'serial-cable-replacement', so it might be RS-485 at each end and the radios in between are just a minor footnote. Digi sells 900Mhz units like this which can do 45 miles 'line of sight'.

The more common 2.4Ghz units can do from 500-feet to 1 mile between nodes of a mesh (radio is always hard to predict with special tools). These very successful designs use simple ZigBee nodes to do serial-encapsulation (like Modbus/RTU) on an auto-healing mesh. One example are solar sites, with meters, inverters, weather-stations all running Modbus/RTU. Another example are the chiller/cold-room compressors on building roofs. You might have 20 units within a few hundred feet, and the metal enclosures are 'radio-leaky' enough that the internal antennas allow Modbus/RTU to be 'meshed' past all 20 units. The 'master' system is often an Ethernet unit (like the Digi X4) which can bridge Modbus/TCP to Modbus/RTU-encap in ZigBee.

But for this discussion, the devices are STILL serial RS-485 Modbus/RTU nodes, which link to a radio-to-RS-485 adapter. And instead of $1000 per pair, a simple RS-485 to radio can be near $100 (embedding the serial radio can be down below $20).

The problem with the Modbus/TCP-to-radio is still the instant customers think of this, they always want HTTP web pages and FTP and DHCP and email (etc) to work over the radio. I have yet to see any company ballsy enough to create a simple Modbus/TCP *ONLY* radio which could pump 9600-baud like comms between 50 nodes of auto-healing mesh within a square mile radius! :)

Has anyone seen such things?
 
S
> This may be crazy talk, but are there sites that implement wireless Ethernet/Modbus?

I’m commissioning a project like that right now (like Lynn says, 1 Modbus/TCP master and less than 10 slaves). 900MHz, 1-15 mile range. I know people doing this on a routine basis (not sure if they’re using Modbus/TCP or something proprietary like EIP, but probably the same from your point of view). I’ll see if I can get one of those guys to comment on this thread.

The reason we wanted to go to Ethernet radios is that the primary device on the slave end is a PLC, and 9600 baud RS485 was perfectly adequate for programming or Modbus data transfer to a central site HMI, but not both. The RS485 ports would want to be set up as programming or Modbus and wouldn’t switch back and forth dynamically.

Fortunately, so far my customers aren’t doing like Lynn suggests and wanting FTP, http, DHCP and so on, all over the radio link. The PLC and near- and far-end radios all have web pages for configuration and status monitoring, and we look at those, but so far I’ve not been asked to stream YouTube out there or anything like that.

Lynn, if I read your post correctly, you’re saying there are standalone RS485 radios, not embedded components, for $100. Whose are you talking about? The least expensive 900MHz units I’ve seen are the Digi XTend’s and for 2.4G, B&B’s ZLinx family. We’re still using 485 from the PLC at the slave end of the Ethernet to some satellite sites (primarily just dumb Modbus I/O at a mile or two from the PLC site. I’d definitely be interested in a $100 packaged product.
 
L

Lynn August Linse

> Lynn, if I read your post correctly, you’re saying there are standalone RS485 radios, not embedded components, for $100.

Steve, I was trying to avoid 'salesman' talk, but the Digi Xtend (plus B&B & others) tend to be higher power - up to 1-watt - so cost more.

What Digi calls the 'Xbee adapters' should be out at stockists (like digikey?) for from between $89 to $109. However, the 2.4Ghz will have 63mw radios and even the 900Mhz version of the same may be in range 50 to 250mw only.

So is 1000mw better than 63mw? When doing a mesh, raw power is actually a LIABILITY. If you have 1 master/base node and 10 remotes which need to home-run back to it, you want raw power for max distance, but if you create a mesh where nodes auto-forward, then you want lower power so that (in theory) different parts of the mesh can work in parallel. In a mesh (in theory) you want each node to only have enough power to reach a few other nodes, but no more ... in theory :)
 
S
Thanks, Lynn! I'll be sure to take a look at those. Understand about the mesh, but so far the distribution of the slave nodes has been more of a star relative to the master. . Will bear that in mind though if a mesh-friendly distribution arises.
 
Top