Automation Network Protocols

8/12/2019 Automation Network Protocols

1/20

rom the Forum department...

Automation network protocolsPosted by Ahmad El-Asmar on 12 June, 2010 - 9:24 am

Hey

I am new to the field of automation.. two months only.. i am working as sales and service engineer.. i am eager tolearn more technical stuff about automation..

Please reply to me with a detailed answer about the definitions and the differences between the following protocols:

1)Modbus

2)Profibus (Siemens)

3)Profinet (Siemens)

4)Fieldbus

5)HART

6)DH+ (AB)

7)ControlNet (AB)8)DeviceNet (AB)

9)Ethernet IP (AB)

10) 4-20mA

I get so confused when i hear those names..I have read a lot about them, but i still cant grasp it very well..

Which of them works on Ethernet TCP/TP and which works on RS-485 or RS-232..is this related to them anyway?

Please guide me.

Posted by M Griffin on 12 June, 2010 - 4:06 pm

1)Modbus - Comes in several varieties:

a) Modbus RTU - Meant for serial (RS-232, RS-485) communications.

b) Modbus ASCII - Similar to Modbus RTU, but encoded in ASCII (rather than raw binary). I believe it is mainly

used for radio links.

c) Modbus/TCP - Similar to Modbus RTU, but adapted for Ethernet.

Modbus is a geniunely open protocol and very widely used. A few people have also created derivative extendedversions which are based on, but not 100% compatible with Modbus.

2)Profibus (Siemens) - Uses RS-485. Has significant third party support.

3)Profinet (Siemens) - Uses Ethernet. This is intended as the replacement for Profibus. It is a closed and

proprietary protocol.

4)Fieldbus - More properly known as "Foundation Fieldbus". Uses a serial network (I don't believe it uses a
http://www.control.com/member.php?m=mgriffin2http://www.control.com/member.php?m=mgriffin2http://www.control.com/member.php?m=mgriffin2


2/20

"normal" electrical specification however). Intended specifically for special applications in process industries.

5)HART - Allows for serial communications over 4-20 mA current loops. Intended for upgrading communications

over existing analogue loop wiring.

6)DH+ - Proprietary to AB. The media and electrical specifications are similar to RS-485. This is more or less

obsolete today.

7)ControlNet (AB) - Prorprietary to AB. The media and electrical specifications are proprietary. This is more orless obsolete today.

8)DeviceNet (AB) - Prorprietary to AB but licensed to third party partners via an organisation called ODVA. The

cabling is proprietary. The electrical specifications and lower level network protocols are based on CAN (with the

DeviceNet protocol layered on top of CAN). It has limited bandwidth and is intended for simple sensor networks.

9)Ethernet IP (AB) - Uses Ethernet. Proprietary to AB, but licensed to third party partners via an organisation

called ODVA.

10) 4-20mA - Not a network. This is an analogue signal. The amount of current is modulated in the circuit betwee

4 and 20 mA to represent a value (e.g. 4 mA is 0%, 20 mA is 100%).

There are many other protocols as well, but since you haven't asked about them, I won't bring them up. The reason

for so many is simple. Most large vendors want to own every aspect of what they sell so they can limit third party

competition.

I'll re-arrange your list a bit differently:

1) Obsolete AB protocols - DH+, ControlNet.

2) Current AB protocols - DeviceNet, Ethernet/IP.3) "Obsolete" Siemens protocols - Profibus.

4) Current Siemens protocols - Profinet.

5) Non-proprietary protocols - Modbus.

6) Process industry networks, analogue loops and analogue upgrades - Foundation Fieldbus, 4-20mA, HART.

I referred to Profinet as "obsolete" because Siemens intended to have Profinet replace it. However, Profinet does

seem to have caught on a well as Siemens had hoped, and lots of their customers are still using Profibus.

Posted by Ahmad El-Asmar on 13 June, 2010 - 3:11 am

I really don't know how to thank you Mr. Griffin! Thank you so much. You have clarified it for me in a very eas

and detailed way! I really hope i can be your employee! lol

I have another question regarding PLCs, which is confusing me.. I know the difference between transistor outpu

and Relay output, but I don't know when to use this or that.. Would you tell me as well? I am shy honestly to ask

more, but i am thirsty to learn and no one's helping me here in the office.


3/20


Relay PLC outputs are typically used when:

1) You require 120VAC or 230VAC outputs,

2) or when you need a "dry contact" to interface with something,

3) or when you have to deal with a variety of different voltages at the same time,

4) or when the current draw is too high for a transistor.

Transistor outputs are typically used when you are dealing with 24VDC control voltages.

When properly applied, transistor outputs tend to be more reliable and have a much longer life than relay

outputs. Relay outputs tend to have a limited service life, but are sometimes favoured because they can make

the overall installation cheaper (you don't need to add external relays for non-24VDC control voltages).

Posted by KirkC on 13 September, 2010 - 1:55 am

MG wrote:

>When properly applied, transistor

>outputs tend to be more reliable and

>have a much longer life than relay

>outputs. Relay outputs tend to have a

>limited service life, but are sometimes

>favoured because they can make the>overall installation cheaper (you don't

>need to add external relays for

>non-24VDC control voltages).

This topic probably belongs on another thread and I'll defer to you or anyone else who knows what he is

talking about, but solid state relays got a reputation in the early 90's for failing closed, sometimes in groups,

depending on the wiring. I've seen it happen. It's not that they fail, everything fails. It's failing closed that is th

problem.

I haven't looked at this for a while. I don't know. Is OK to use these now?

Posted by Steve Myres on 13 S eptember, 2010 - 10:27 am

I think both answers are incomplete. I think solid state DC outputs have their place and relay outputs do as

well. Remember the original poster said DC outputs are superior "when properly applied". Well if an output

channel isn't a "proper application" for a DC output, what is one to do? Obviously using a relay output is one

option. If you have a easy-to-switch DC load that switches 100 times an hour, you definitely don't want a
http://www.control.com/member.php?m=KirkChttp://www.control.com/member.php?m=mgriffin2http://www.control.com/member.php?m=mgriffin2


4/20

relay. Now, I will NEVER use a triac AC solid state output. All the ones I've ever seen leak, sometimes

enough to turn on the load, and they do fail at an unreasonable level.

Posted by M Griffin on 13 September, 2010 - 1:13 pm

In reply to KirkC: Most of this thread is so far off the original topic that I don't think another digression is

going to matter much. If everyone stayed on topic, I doubt that many of the regulars would bother to answequestions anyway.

When you talk about "solid state outputs", you have to draw a distinction between triac outputs for 120VAC

(or 240VAC) and 24VDC transistor outputs. Triacs were often very problematical, but they are rarely used

these days anyway. Most PLCs installed today (and for some years now) use 24VDC as the control voltag

Modern 24VDC transistor outputs are normally very reliable, and rarely fail. Some brands of PLC may hav

quality or design problems, but in my own experience has been that a typical modern PLC installation using

24VDC transistor outputs will have no failures during its service life, while one using relay outputs will have

multiple relay failures during its service life.

The problems you describe sound like they may have been problems with a particular vendor's product

design or manufacturing quality. Even in the early 1990s the 24VDC transistor outputs that I used were

clearly more reliable than relay cards.

Part of the problem with relays is that the relays used these days seem to be of much lower quality

compared to those used in the early 1990s and fail much sooner due to mechanical life. On the other hand,

transistors have gotten much better since then. In addition, the types of loads we are using have changed a

lot as well. The common pneumatic valves are optimised for low power 24VDC operation, meaning that

PLC output life will depend on mechanical wear, with transistors having an indefinite life in that respect.

If I have to use a few relays for power handling or compatibility reasons I prefer to use external plug-in

relays so they can be replaced quickly and easily.

If you have a small application where the outputs switch only occasionally, relay outputs might still save you

some money. However, most end user customers are better off just specifying 24VDC transistor outputs

across the board in all applications and allowing exceptions on a case by case basis in unusual

circumstances.

Posted by Dick Caro on 13 June , 2010 - 9:32 am

I don't know what the question was, but this is an incomplete answer. All of the protocols mentioned are defined

by IEC standard 6115, which makes all of them standards not proprietary except for DH+. DeviceNet is also an

international standard except it is defined by a different ISO standard.

Dick Caro

===========================================

Richard H. Caro, Certified Automation Professional, CEO, CMC Associates,

2 Beth Circle, Acton, MA 01720 USA
http://www.control.com/member.php?m=mgriffin2http://www.control.com/member.php?m=mgriffin2


5/20

E-mail: [email protected]

Subscribe to the CMC Wireless Report

Web: http://www.CMC.us

Posted by David on 13 June, 2010 - 2:37 pm

I find Mr. Griffin's assessment very pragmatic and real world. Well done.

I would only add that the 'upgrade in communications" that HART provides is

- primarily field instrument configuration;

- second, multiple process variables;

- third, field instrument diagnostics.

Standard communication is just the primary process variable over 4-20mA. All the other goodies require HART


In reply to Dick Caro: I described the following protocols as "proprietary": Profinet, DH+, ControlNet,

DeviceNet, and Ethernet/IP. You cannot (or at least the vendors claim you cannot) implement any of those

without obtaining a license from the vendor or licensing organisation. I didn't mention the status of Foundation

Fieldbus, HART, or Profibus because I don't know the terms and conditions (if any) for those.

Having a standards number is an entirely different question from whether or not something is "open". It's all a

question of the terms and conditions. Many (if not most) standards organisations consider licensing matters to b

outside of their concern. On the other hand, a number of companies have documented protocols that they useand allow anyone to implement them freely.

If you don't consider terms and conditions to be relevant, then everything is "open". After all, you can always

just buy the company, can't you?

This by the way isn't intended to say anything against the work of people who participate in official standards

committees. I'm sure they do useful work. However, there is also a lot of very useful word done by unofficial

groups and interested parties who work outside standards organisations but who also write protocol (and other)

specification documents.

Also, I would like to mention that many "standards" don't actually specify what they are standardising. They

simply reference another document or organisation for the actual specifications. That is, standards document

"123" may simply state that document "abc" from another party is now a "standard" so far as they are

concerned. For example, the notorious ISO/IEC 29500 simply handed over authority to ECMA, whose own

committee was run primarily by a single vendor. The ECMA committee in turn defined a number of areas as

"do it like the original vendor does it" without actually specify what the behaviour was (it was considered to be

trade secret). The ISO committee approved it without ever seeing the actual final document they were voting o

(which wasn't released until 6 months after the vote).

Customers are increasingly looking for "open standards". Unfortunately, many corporate marketing department
http://www.control.com/member.php?m=mgriffin2http://www.control.com/member.php?m=mgriffin2http://www.cmc.us/http://www.cmc.us/


6/20

are responding to that by going through the motions without actually conceding anything of substance. It is still

very much a case of caveat emptor.

Posted by curt wuollet on 13 June, 2010 - 9:51 pm

It's interesting because that seems to be what the current flap is all about, standards that are a "trojan horse"

for someone's IP. A standard that exposes you to patent trolls and other odious litigation isn't remarkablyhelpful. Standardization should be in your best interest. Perverting the process to plant time bombs is what the

new sheriff wants to eliminate.

Regards,

cww

Posted by Ahmad El-Asmar on 14 June, 2010 - 1:39 am

Again, I thank you so much Mr. Griffin! I really am grateful for you.

And thanks to all as well.

Posted by Steinhoff on 14 June, 2010 - 3:26 am

> In reply to Dick Caro: I described the following protocols as "proprietary": Profinet, Having a standards number is an entirely different question from whether or not something is "open". It's al

a question of the terms and conditions. Many (if not most) standards organisations consider licensing matters to be outside of their concern. On the

other hand, a number of companies have documented protocols that they use and allow anyone to implement

them freely.


7/20

Yes, and these companies can change their specification all the days and can also hide important features.

And for the next version of their specs you have to pay a big license ... freely :)

> If you don't consider terms and conditions to be relevant, then everything is "open". After all, you can alway

just buy the company, can't you? "This list contains patents that are relevant to PROFIBUS, PROFIsafe, PROFIdrive and/or PROFINET

technology. The patents are granted to all members of PROFIBUS International for products being

equiped with a PROFIBUS and/or PROFNET interface.">

> So, they are claiming that you need a license from them to implement Profnet or Profibus. am not in a position to judge how significant these patents are, but an "open" specification would normall

simply provide an automatic patent grant.


9/20

That's not the case. Every patent is open specified ... but you have to pay licenses for patents.

> As for OVDA, you have to apply for membership, sign a contract, and purchase a license. They can

revoke your license at any time, and if they revoke your license you lose all rights including those attached

to your existing products or software. The only "open" involved in ODVA is in the name. Sorry, they are not claiming that you need a license to implement PROFINET or PROFIBUS. As a

member of the PROFIBUS user group I have never signed a license agreement. That's not the case. Every patent is open specified ... but you have to pay licenses for patents. * The only bus with function block diagram language (IEC 61804-2) * The only bus with scheduled control execution and communication * Separated real-time and non-real-time communication * Alert distribution * The only bus with tag-based plug-'n'-play * Peer-to-peer communication * The only bus supporting a temporary master > * The only bus supporting a temporary master

> That's kinda cool. * The only bus with scheduled control execution and communication Virtually ALL modern buses have this. ControlNet, EtherNet/IP, EtherCAT, ProfiNet...> * Separated real-time and non-real-time communication SERCOS III and EtherCAT both have this. Others may as well. No automatic address assignment.

Automatic address assignment is very common with Ethernet (DHCP). It just isn't worth the effort for

most factory networks however, as they are relatively small and isolated. Also, some industrial protocolscarry additional addressing requirements on top of Ethernet because they carry legacy baggage from the

RS-485 networks they were based on.

> Not scheduled/synchronized

That (as you said) is not really useful for most factory automation applications. However, some versions o

Profinet (and some other protocols) do this which is how they synchronise servo systems. As I've said

before however, I don't see this as a feature I would worry about when choosing a general purpose

protocol as you can always install something special for the servo system. The situation may be different

however with process applications, as scheduled / synchronized operations might be most of what you

would do there.

> No report by exception

Report by exception is intended to help with network bandwidth problems. Network bandwidth is rarely a

problem in factory automation over Ethernet, so you don't need report by exception there. For large scale

backbone plant supervisory networks, I haven't seen any existing automation protocols which I think are a

good solution.

> No temporary master: is OK for indoor PLCs that

> don't drift and don't wear

If your PLC (or any other component) is down, then generally your machine is down. That applies to even

minor components such as proximity sensors. In a factory there is typically no redundancy. You just

concentrate on getting it back up and running as quickly as possible.

I realise that in the process industries there may be specific application considerations which FF tries to

address. It is usually the case that a specialised protocol will address a narrow field better than a

generalised protocol would. On the other hand, the things which make a specialised protocol better for one

field may make it unsuitable for for other different fields.

If on the other hand we look at just the factory automation field, we see some very complex as well asvery simple protocols. The complex factory automation protocols exist for basically two reasons:

1) Address vendor legacy issues. This is usually the biggest reason. The vendor has legacy hardware or

protocol problems which they wanted to provide backwards compatibility with. They made some design

decisions in the past which may or may not have been a good idea, but they're stuck with them now. Ther

is no advantage to the customer however unless they have a factory full of legacy hardware from that

vendor that they need to integrate. If you are not in that position, then the complexity is in fact a big

disadvantage.


19/20

2) Marketing specialised applications under a common brand. The vendor wants to sell their general

purpose, servo, and safety protocols under a common brand name, so they say they are all one protocol.

The end user however has to ask himself the question of whether he wants to be locked into a single

vendor for the sake of saving a $3 Ethernet cable? For most people, it makes no sense. Now, if you decid

that you want all your stuff from that single vendor anyway, then that's not a problem if their protocol

*can* do that. On the other hand, it can't really be said to be an advantage either.

I've never seen a factory where *everything* came from a single vendor. You almost always have to

integrate components from multiple companies because the company that makes good PLCs doesn't makweld controllers or press force monitors. The most difficult challenges in many factory automation designs

is trying to find some way to get the PLC from vendor "A" to talk to anything that didn't also come from

vendor "A" or one of their selected "partners". Things might be a bit different in process industries, but

that's what we have to deal with in the factory.

Posted by Jonas Berge on 30 September, 2010 - 10:42 am

In reply to mgriffin (13 September): I agree automatic address assignment is not necessary if you just

have a dozen PLCs on your network. It is when you have hundreds or thousands of sensors and

actuators networked in the field that automatic address assignment is indispensible.

I agree the requirements for factory automation, process control, and motion control servo are different

and that a general purpose protocol do not do either one as well as a special purpose protocol.

I agree that report by exception makes most sense for low bandwidth applications with many nodes - for

data that does not change very often.

I agree that one of the many ways process control is different from factory automation is that a node

(such as a transmitter or analyzer) may be down without the process unit being down so you just need tofix this one node while the rest is still running. And perhaps even more important, you may need to work

on that node even though it is not "down". You just need to calibrate or routine check it to make sure it is

accurate. See this article highlighting differences between process control and factory automation:

http://www.ceasiamag.com/article-5506-thefieldbusyears-LogisticsAsia.html

For the longest time it was believed by many that protocol preference was based on the part of the worl

your plant is in, but that is not the case. Protocol preference boils down to its features addressing the

application requirements: process, factory, building, or motion. FF is for process control in any part of th

world. I wonder which analyst will first discover this.

I agree specialized protocols have a niche where they are the best fit. I would not use anything other thFOUNDATION fieldbus for process control. Conversely I would not use FOUNDATION fieldbus for

anything other than process control.

I agree that trying to address all kinds of automation with a single protocol would make it very complex.

What we find is that a "suite" of several protocols (which are very different in some ways but have

something in common) address different application needs but lumped under a common brand.

I agree that no manufacturer makes all the devices or networking hardware required for the many kinds

of plants out there. Its the same for process control. This is why an interoperable standard is so
http://www.ceasiamag.com/article-5506-thefieldbusyears-LogisticsAsia.h


20/20

important. And this is why more than a hundred companies make products for FOUNATION fieldbus

(IEC 61784-1 profile 1/1 of IEC 61158 type 1): different solutions to meet needs of different applications

yet compliant to a common protocol. I believe it is the same for standard factory automation protocols.

Cheers,

Jonas

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy.

Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal

Notices, the content of this site and the compilation thereof is 1999-2014 Nerds in Control, LLC. All rights reserve

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.

FortuneJone's Motto:

Friends come and go, but enemies accumulate.
http://www.control.com/ie6b.phphttp://httpd.apache.org/http://www.mysql.com/http://www.php.net/http://www.control.com/about.php#privacyhttp://www.control.com/about.php#legal

Automation Network Protocols

Documents

Transcript of Automation Network Protocols