from the Forum department...

Automation network protocols

Posted 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 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.
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 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.
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 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.
Posted by M Griffin on 13 June, 2010 - 3:41 pm
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 the
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 September, 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
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 answer
questions 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 voltage.
Modern 24VDC transistor outputs are normally very reliable, and rarely fail. Some brands of PLC may have
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
E-mail: RCaro@CMC.us <mailto:RCaro@CMC.us>
Subscribe to the CMC Wireless Report <http://www.CMC.us>
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.
Posted by M Griffin on 13 June, 2010 - 4:44 pm
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.
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 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
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, <
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
Posted by curt wuollet on 14 June, 2010 - 12:51 pm
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
Posted by M Griffin on 14 June, 2010 - 5:44 pm
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/downloads/downloads/list-of-patents-to-p rofibus-profisafe-profidrive-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.
Posted by Steinhoff on 15 June, 2010 - 4:23 am
----- 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
Posted by M Griffin on 15 June, 2010 - 3:39 pm
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.
Posted by Ron Mitchell on 19 June, 2010 - 1:35 pm
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!!
Posted by curt wuollet on 20 June, 2010 - 1:17 am
In my case, about $600 more open would be good. By definition, restricted does not equal open.
Regards,
cww
Posted by Jonas Berge on 16 July, 2010 - 9:29 am
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
Posted by Ken E on 16 July, 2010 - 12:04 pm
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
Posted by James Ingraham on 16 July, 2010 - 12:43 pm
> * 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.
Posted by M Griffin on 16 July, 2010 - 11:02 pm
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.
Posted by Jonas Berge on 12 September, 2010 - 7:45 am
Dear Griffin (16 July),
But many protocols are not using Ethernet and TCP/IP because they want long distance, don't want LAN
switch, and want bus topology etc. and these protocols are not peer-to-peer. Take Modbus/RTU or
PROFIBUS-DP over RS-485 for instance.
Perhaps it could be said that this is the distinction between master/slave and client/server? Master/slave is
when the protocol only supports a single master, while client/server is when the protocol supports multiple
masters.
Temporary master is not designed as a workaround for some protocol problem. Temporary master is a solution
to a common problem in process control industries: transmitters need to be calibrated, it cannot be done
remotely, so often it is done in the field. See here:
http://www.eddl.org/DeviceManagement/Pages/Calibration.aspx
Same goes for valve stroking and many other tasks. Temporary master was designed into FOUNDATION
fieldbus to meet this requirement.
Cheers,
Jonas
Posted by M Griffin on 12 September, 2010 - 4:52 pm
In reply to Jonas Berge: Master/slave and client/server are exactly the same thing. They are just analogies
that have different historical origins. The automation industry analogy was of a slave master driving a gang
of slaves, while the IT industry analogy was a waiter (server) serving a number of diners (clients) in a
restaurant. In either case however, the client (or master) sends a "request", and the server (or slave) sends a
"response". The behaviour of the client or server versus the master or slave are identical.
The client/server term is now being used in automation because of the adoption of technology from the IT
industry (such as Ethernet). The existing literature for things such as http is going to refer to clients and
servers rather than masters and slaves.
Posted by Jonas Berge on 31 August, 2010 - 8:30 pm
SERCOS and EtherCAT were not in the list in the original post so I did not consider those. The list didn't include
Sync version of CIP. But yes, you are right, these motion control kind of buses all have time synchronization.
FOUNDATION fieldbus combines communication and programming language so that the bus is not only used
to communicate values between function blocks in different devices, but the bus is also used to schedule when
function blocks in the different devices shall be executed. This ensures distributed control functions execute in
the right order from inputs to outputs.
I did not find anything on scheduling of control logic function execution in ControlNet, EtherNet/IP, EtherCAT,
and ProfiNet literature - only scheduling of communication. So I believe this may be unique to FF.
SERCOS and EtherCAT were not in the list in the original post so I did not consider those. But you may be right
they might have separated communication. Motion control have requirements similar (and often even more
extreme) than PID loops.
Indeed there are many sites with process control instrumentation that do PID loops without FF. Many are
analog - digital communication not part of the closed loop. Digital communication is involved some closed loop
control, for instance across an I/O backplane bus or remote-I/O bus. If the bus is not synchronized with the
control execution there will be unnecessary delays and jitter, which are not good for PID control. FF is
synchronized and scheduled, thus minimizing delays and jitter, and therefore well suited for PID loops. Motion
control busses are synchronized for the same reason, but they do not provide bus power and are not intrinsically
safe so not suitable for instrumentation. So FF is the bus best suited for PID loops and process control
instrumentation.
PROFIBUS-PA does provide bus power and intrinsic safety, but is not synchronized and scheduled since it is
the same data link layer as PROFIBUS-DP. PROFIBUS address assignment is manual which is OK for a
couple of drives but I personally think it will be hassle for hundreds or thousands of instruments. Instruments
need field calibration i.e. connection of temporary master but a temporary master with PROFIBUS is not so
practical. FF has automatic address assignment and supports ad-hoc masters, so FF is the bus best suited for
PID loops and process control instrumentation.
Agree. FF is not the only game in town. I personally believe FF is best the best choice for process control, but
other busses are ideal for motor control, motion control, and other tasks.
Cheers,
Jonas
Posted by Dick Caro on 1 September, 2010 - 8:20 am
Jonas was absolutely right about Foundation Fieldbus being ideal for distributed PID control. The motion
control buses all have protocol mechanisms to eliminate jitter depending upon the time constants required for
the motion actions. Clearly, metal cutting motion control is far more demanding than assembly robotics, and
both of these are more demanding than process control. Foundation Fieldbus offers the additional capability for
sequence scheduling across the network. Any motion control sequence scheduling must be done in the control
logic, not by the network.
One thing that Jonas did not mention, is that the Ethernet back haul protocol for Foundation Fieldbus (called
HSE, for High Speed Ethernet) also participates in the same scheduling domain as the local H1 link. This
enables tight time synchronization between function blocks that happen to be located on different H1
segments. This applies only to process control, but is also unique to Foundation Fieldbus.
Posted by c sHEKHAR on 1 September, 2010 - 10:38 am
What is client server technology. What is the importance of knowing it for proper functioning of PLC.
Posted by M Griffin on 1 September, 2010 - 2:41 pm
"Client server technology" is simply the method used in almost all digital communications. The "client" sends
a "request", and the "server" sends a "response". The client can then repeat that cycle as many times as it
wishes.
In industrial communications this was for historical reasons referred to as "master/slave". That term is falling
out of use however as communications technology from the wider IT field (e.g. Ethernet) is becoming used
more frequently in industry.
I have an explanation with a bit more detail on my web site:
http://mblogic.sourceforge.net/mbapps/ComBasics.html
Most communications protocols use the client/server model because it is simple, reliable, and doesn't require
a lot of complex configuration by the user. The few protocols that don't are typically intended to address a
very narrow problem (e.g. very limited bandwidth).
Posted by Demigrog on 2 September, 2010 - 4:10 pm
> Hardly. SERCOS has time synchronization. EtherNet/IP has CIP Sync. EtherCAT can do time sync. I'm not
sure about ProfiNet. <
In FF, communications between devices is scheduled as part of a macrocycle. Not the same thing as simply
syncronizing clocks.
> 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. <
FF Blocks execute in the field devices, and the bus protocol handles the scheduling and transfer of values
between the devices.
>> * The only bus with scheduled control execution and communication <<
>Virtually ALL modern buses have this. ControlNet, EtherNet/IP, EtherCAT, ProfiNet...<
Not really; the feature is only really relevant in FF, as it has blocks executing in the field devices.
>> * Separated real-time and non-real-time communication <<
> SERCOS III and EtherCAT both have this. Others may as well. <
In FF, a portion of the macrocycle is reserved for non-scheduled communications. Again, without field execution
of blocks there isn't much need for this in other fieldbuses.
>> * Peer-to-peer communication <<
> ControlNet, EtherNet/IP, and ProfiNet all do this. <
Peer meaning actual field devices; Valve A and Valve B communicating with each other and participating in a
control loop without the intervention of a controller or PLC.
Posted by M Griffin on 2 September, 2010 - 8:15 pm
A lot of what is being said about Foundation Fieldbus versus other protocols is really just a matter of
semantics. Things like function blocks are *not* part of the wire protocol, regardless of whether or not they
appear in the FF spec. FF is defining a general process industry platform that happens to include a
communications protocol, while the other protocols simply define the communications protocol itself and not
the rest of the platform. If you want to compare Foundation Fieldbus to Allen Bradley Ethernet/IP, you need to
include the capabilities of AB's PLCs (or other devices) in the equation.
As to whether or not the FF approach is better for the narrow market segment that it is targeted at is a
question that I will leave to others. I don't consider it to be suitable for general purpose factory automation
however (nor is it intended to be). I would put it in a class of its own rather than lumping it in with other
protocols.
As for the pros and cons of the other protocols, you really have to look at what you would do with the actual
features. Having a nice long list of features may look good on a brochure, but most people will never make use
of most of them. It's usually better to have something simple that fits 99% of your applications and address the
other 1% on a case by case basis. What probably matters more is whether you are going to be able to
maintain the system over the long run, in which case having a lot of "unique" features in a protocol tends to
work against you.
Posted by Jonas Berge on 12 September, 2010 - 7:44 am
Dear Griffin (2 September),
An important part of FOUNDATION fieldbus (FF) is how wire protocol scheduling and function block
execution scheduling tie together to form a system synchronized end-to-end, sensor to valve.
For PID control in the function block (diagram programming language part of FF) sampling is important.
Since sampling and control is distributed across devices and rely on communication and common scheduling
for synchronization it is important that the protocol for process control and programming language are
designed together. I personally believe FOUNDATION fieldbus is uniquely positioned to meet the specific
needs of process control.
I agree FF is targeted for the "narrow" process control market segment.
I agree that FF is not the choice for general purpose factory automation, building automation, power grid, or
motion control etc. FF is for process control.
I agree FF is in a class of its own
I agree that the you need to select the protocol based on the application. For motion control I would select
something different.
Every protocol has a nice long list of features (and FF is the only protocol for which there is no brochure!). I
only brought up those features that plants actually use, which do add value. There is stuff in the FF protocol
that is not being used/implemented which I did not mention. Plants are not even aware that they use unique
FF features. Technicians connect a replacement transmitter on the bus and it automatically gets an address.
They don't invoke any "automatic address assignment feature" so they don't even think about the feature
being there. Similarly, plants take for granted that they can connect a handheld communicator to the running
bus, they don't realize this is another feature they are using.
In principal I agree that simple is good, provided the application requirements are met. For instance, Modbus
is a simple protocol that do a lot of jobs well. However, in my personal opinion, the simplicity also has
drawbacks that makes it non-ideal for process control instrumentation. Same goes for many other protocols.
For example: - No automatic address assignment: is OK for a handful of PLCs but makes hundreds or
thousands of field instruments impractical to manage - Not scheduled/synchronized: is OK for factory
automation but not PID - No report by exception: is OK for a handful of PLCs but inefficient for hundreds or
thousands of field instruments - No temporary master: is OK for indoor PLCs that don't drift and don't wear,
but a hassle for hundreds or thousands of instruments requiring occasional attention in the field
I suppose for the same reason many sophisticated features are available in the DeviceNet and EtherNet/IP
and other protocols so they can support applications more advanced than basic data acquisition.
Many of the features of FOUNDATION fieldbus fall in the category of "system management" and "network
management". These are features which are not directly concerned with making the split-second
communication faster, but to towards making the system easier to maintain over the long run. That is,
features done the right way makes life easier. But I agree, gadgetry would just make things more difficult to
use.
Cheers,
Jonas
Posted by M Griffin on 12 September, 2010 - 6:54 pm
In reply to Jonas Berge: When I was referring to simplicity of the protocol being an advantage for most
applications, I had already drawn a distinction between Foundation Fieldbus and factory automation
protocols. I put FF is a class by itself, and intended the "simplicity" argument to apply only to factory
automation applications.
In factory automation applications, the vast majority involve something like "read the inputs, solve a series
of rungs of ladder, turn the outputs on or off". You then repeat that every few tens of milliseconds. You
also have to interface motion controllers, weld controllers, RF readers, bar code readers, etc., but those
generally involve just occasionally sending a command or parameter and doing a handshake.
In factory automation, most network protocols can be thought of as extensions to the PLC backplane. They
let you save on wiring costs between the PLC CPU and the valve banks and sensors. What you want to do
is to copy the PLC I/O table between the CPU and the remote I/O as quickly and simply as possible. With
100Mb Ethernet, bandwidth is rarely a problem. The limitations are usually in the processing power in the
field racks (or I/O blocks) or PLC. In those cases, a simple brute force approach is usually *much* faster
(and cheaper) than anything which requires running sophisticated communications algorithms. This is one
of the reasons why the "simple" approach can work so well.
I'll address some of your points directly:
> 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 protocols
carry 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 of
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 as
very 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. There
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.
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 decide
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 make
weld 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 to
fix 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.h tml
For the longest time it was believed by many that protocol preference was based on the part of the world
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 the
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 than
FOUNDATION 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
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 reserved.
Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.
Fortune
Jone's Motto:
Friends come and go, but enemies accumulate.