Hey

I am new to the field of automation.. two months only.. i am working as sales and service engineer.. i am eager to learn 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.

 

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 extended versions 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 "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 or less 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 between 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 doesn't seem to have caught on a well as Siemens had hoped, and lots of their customers are still using Profibus.

 

I really don't know how to thank you Mr. Griffin! Thank you so much. You have clarified it for me in a very easy 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 output 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.

 

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
E-mail: [email protected] <mailto:[email protected]>
Subscribe to the CMC Wireless Report <http://www.CMC.us>
Web: http://www.CMC.us

 

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.

 

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).

 

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 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.

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 a trade secret). The ISO committee approved it without ever seeing the actual final document they were voting on (which wasn't released until 6 months after the vote).

Customers are increasingly looking for "open standards". Unfortunately, many corporate marketing departments 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.

 

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 remarkably helpful. Standardization should be in your best interest. Perverting the process to plant time bombs is what the new sheriff wants to eliminate.

Regards,
cww

 

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

And thanks to all as well.

 

> In reply to Dick Caro: I described the following protocols as "proprietary": Profinet, <

Sorry Profinet is not a proprietary protocol ... it is just the follow up of Profibus. It is based on a complete open standard and if you want to implement it you haven't to pay any licenses.

> 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. <

I don't know how the ODVA is maintaining the "openness" of their fieldbuses, but Profibus was the first complete open fieldbus standard and it is it until today.

> 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. <

It is not only a question of terms and conditions. It depends on an open specification released by a standardization group.

> 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. <

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 always just buy the company, can't you? <

OK ... then buy Microsoft in order to get their proprietary server protocols

Regards
--Armin

 

I think it would be best to say that the vendor side of the automation world wants the term Open to be a continuum. From meaningless advertising with a completely closed product like MS Windows, which we often see described as open in these pages, which proves the advertising is believed by someone, to something you can use, but is encumbered and still controlled by them. This is not particularly consistent with the definition of Open the OSS world uses. I have sort of settled on a test of Open, which all the OSS software meets and unfortunately, almost all of the automation software and protocols don't. It's really simple:

Can I use the software or protocol to _my_ benefit without buying anything or licensing any thing, (which doesn't mean it's not licensed) or certifying anything. Is it documented to the point where it can be completely understood with sufficient detail that I, (or a competent programmer), can implement it, or in the case of software do I get (accurate) source code.

The criteria is simple. That's generally what I need to do. If I can't so what I need to do with a protocol or software item, without paying tribute, it's not Open.

Regards,
cww

 

In reply to Armin Steinhoff: The Profibus/Profinet organisation claims that these protocols are covered by patents held by their members. E.g.:

http://www.profibus.com/nc/download...rofidrive-and-or-profinet-technology/display/

That list is password protected and is not available to the public. However, they state:

"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. I am not in a position to judge how significant these patents are, but an "open" specification would normally simply provide an automatic patent grant.

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.


As for companies changing specifications, that happens even with "official" specs that pass through official standards organisations as well. It's more a matter of whether or not the standard is dominated by a single vendor. When it's dominated by a single vendor, then that vendor can show up at a meeting and tell everyone else what is going to be in the next version of the spec, and they can like it or lump it.

If you want a good example of that, have a look at the programming languages Java and C#. The Java spec is controlled by an unofficial "Java Community Process", while C# is covered by an official ECMA spec. With Java, parties other than Sun (now part of Oracle) have significant input into the Java spec. With C#, third parties (including Novell who have their C#/Mono implementation) find out what is in the next version of the spec by going to Microsoft's annual product exhibitions and listening to the speeches.

There is no process, certification, or standard which guarantees openness. Openness is something that is normally achieved through the good will and effort of the various parties involved. It can sometimes be imposed on someone, but that usually leads to less than satisfactory results.

You said: "OK ... then buy Microsoft in order to get their proprietary server protocols "

You can get the specs now, because the EU competition commission forced Microsoft to provide them (actually, they had to force Microsoft had to write them first, because there were no written specs - all their network communications software was written by the seat of their pants). The EU also forced Microsoft to list all the patents which they claim applied to those protocols. This was something that Neelie Kroes spent years of effort beating out of them because they take the idea of market competition rather seriously in the EU. I doubt we will see this happen with automation protocols however, because it is such an obscure field.

 

----- snip ----
> "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. <

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.

> am not in a position to judge how significant these patents are, but an "open" specification would normally simply provide an automatic patent grant. <

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. <

Interesting version of openess ...

Regards,
Armin Steinhoff

 

In reply to Armin Steinhoff: You said:

> 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. <

Did you write your own implementation of Profibus or Profinet, or are you using one from a third party?

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

Do you know where I can see a list of these patents? On the Profibus/Profinet web site that list is password protected and available to members only.

Also I'm not sure what you are saying about licensing. Licenses for protocols will either come under contract law, patent law, or trademarks. Under contract law, if you don't sign the contract you can still reverse engineer the protocol yourself. Under trademark law, you just can't use their trademark (protocol name) without their permission. Patents tend to be the biggest problem, because you can't even create your own independent implementation. If the Profibus/Profinet organisation (or one of the companies behind it) were to take legal action against someone, it would be under one of these sets of laws. That is what is at question here.

The common way of dealing with this is for all the parties involved with an open standard to grant an automatic patent license to all patents considered essential to implementing the open standard. In the original post which lead to this conversation I didn't list Profibus as "proprietary" because I don't know enough about the terms. Even at this stage I find the organisation's position to be somewhat ambiguous.

 

Downloads from the PROFIBUS International web site are freely available for quite a few documents. As far as the protocol specifications for PROFIBUS and PROFINET, those are IEC documents and must be obtained from the IEC...not PROFIBUS International. Some documents on the PI web site do require membership. That means being a member of any regional PI organization anywhere in the world. The regional membership fees vary, typically by the region and the size of the company. For example, membership in the US organization, the PTO, is less than $600 for a system integrator or a distributor for a PI member company.

As far as license fees, there are none. Being a member of any regional organization confers the right to use any of the technology involving any of the patents. However, I have known companies that have implemented their own PROFIBUS stack, purchased standard ASICs and had their products certified without being PI members...so membership is not strictly required at all.

Several different companies sell PROFIBUS stacks and ASICs as well as PROFINET stacks and ASICs with no license(s) required for purchase. I don't know how much more "open" things could be!!

 

In my case, about $600 more open would be good. By definition, restricted does not equal open.

Regards,
cww

 

FOUNDATION fieldbus (FF) H1 has several unique characteristics setting it apart from the other bus technologies:

* The only bus with time synchronized communication: as required for good PID control

* The only bus with function block diagram language (IEC 61804-2): as required for closed loop control digitally integrated from end-to-end

* The only bus with scheduled control execution and communication: as required for good PID control

* Separated real-time and non-real-time communication: as required for good PID control

* Alert distribution: for timely delivery of device diagnostic alerts

* The only bus with tag-based plug-'n'-play: to make thousands of instruments to manage without address mismatch and duplications

* Peer-to-peer communication: as required for good PID control

* The only bus supporting a temporary master: to connect a handheld or laptop in the field for instrumentation tasks that cannot be done remotely such as sensor trim, observed stroking, and other function tests etc.

That is, FF is the only bus suited for PID loops and process control instrumentation

The other buses do not have the same technical features and therefore are less suitable for process control. Other buses were designed for factory automation for which they are better suited, and should not be applied in process control. Of course there are other things that those buses do very well that FF does not do, so I would not use FF in factory automation for which is was not designed.

To learn more about fieldbus and Ethernet and stuff you did not know about HART take a look at the yellow book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" buy online:

http://www.isa.org/fieldbuses

Cheers,
Jonas

 

Delta Tau's MACRO ring is very synchronized and controls many servos using PID at very fast rates. Devices that support this bus are limited though.

KEJR

 

> * The only bus with time synchronized communication <

Hardly. SERCOS has time synchronization. EtherNet/IP has CIP Sync. EtherCAT can do time sync. I'm not sure about ProfiNet.

> * The only bus with function block diagram language (IEC 61804-2) <

Well, you've got me here. I don't know how a bus implements a language, but I'll admit I don't know of any other buses that do.

> * 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.


> * Alert distribution <

No sure about this one. I don't know how Alert distribution on FF works, so I can't compare it to other networks.

> * The only bus with tag-based plug-'n'-play <

Okay.

> * Peer-to-peer communication <

ControlNet, EtherNet/IP, and ProfiNet all do this.

> * The only bus supporting a temporary master <

That's kinda cool.

> That is, FF is the only bus suited for PID loops and process control instrumentation <

Considering how many sites there are in the world doing PID loops and process control instrumentation without FF, I have to disagree with this conclusion.

> Other buses were designed for factory automation for which they are better suited, and should not be applied in process control. <

This is only partly true. Profibus-PA was certainly designed for process control. ProfiNet may have a factory automation focus, but there's no reason NOT to use it for process.

Note that I'm not saying you shouldn't use FF. Just that it's not the only game in town.

-James Ingraham
Sage Automation, Inc.

 

In reply to James Ingraham:

>> * Peer-to-peer communication <<

> ControlNet, EtherNet/IP, and ProfiNet all do this. <

I think that any straightforward client/server protocol on Ethernet TCP/IP (e.g. Modbus/TCP) is inherently peer-to-peer. You just have to implement both the client and server parts of the protocol. In fact, I can't think of how to *prevent* it from being peer-to-peer.

>> * The only bus supporting a temporary master <<
>
> That's kinda cool. <

Again, it's a work around for problems that not all protocols have.