CIP Motion on Ethernet/IP sounds like it can do fairly accurate motion control with "standard" ethernet with no non-standard parts. However, others tell me this is "not quite true" since you need special parts in your end nodes and switches to handle the IEEE-1588 Precision Time Sync protocol. Does anyone know the true story regarding this. Also, how does this compare to the method for motion control used by Profinet?
I think thats true, you will need a IEEE-1588 infra structure, which for sure will be provided by AB in the future. Alternatives are ETHERNET Powerlink http://www.ethernet-powerlink.org
which really needs only standard Ethernet components. But the network is build in an own real time domain. And of course, the drives must speak EPL.
with best regards / mit freundlichen Grüßen
Don't forget to register to the 11th intl. CAN Conference
+=====================================| port GmbH phone +49 345 77755-0
| D-06132 Halle/Saale mailto:email@example.com
| Germany http://www.port.de
| CAN Wiki http://www.CAN-Wiki.info/
| ETHERNET Powerlink http://www.epl-tools.com
| Newsletter: http://www.port.de/register.html
Yes, I think the degree of IEEE-1588 hardware support affects the accuracy. However, if the infrastrure is "supplied by AB" rather than by the industry as a whole, that rather defeats the "open" nature of CIP, Ethernet/IP and/or CIP Motion. Supposedly, IEEE-1588 support in ethernet devices is of interest to other industry segments such as communication and measurement.
IEEE-1588 (PTP) is a standard with broad applicability in markets such as audio/video streaming etc. so there is noting proprietary or "industrial" about it. We should therefore expect supporting products from many suppliers.
Intel has PTP support in their communication chips. These are the chips you use in motion devices. I suppose there are other vendors as well.
For best performance you also need chips with PTP support in "transparent" switches. I have seen that Hirschmann supports it and I am sure there are others as well.
Instead of your NTP server you use a PTP server "grandmaster clock". Like NTP server they take the time from the GPS system. I have seen Symmetricom and Meinberg.
I also came across NIC for the computers
I can't answer your questions on "Ethernet/IP", but "Profinet" uses a proprietary protocol on proprietary hardware for real time motion control. You can supposedly do ordinary I/O using standard Ethernet, but real time control (for e.g. motion control) on Profinet uses a proprietary layer to reserve network bandwidth for the real time communications.
As to whether you "need" the proprietary features or not depends upon a lot of factors, particularly on how heavily loaded the network is. The proprietary extensions are to guarranty reserved bandwidth for designated applications. If the network is lightly loaded, then standard Ethernet *may* work fine.
At the moment however, the major automation vendors are using Ethernet so they can buy cheaper components. They aren't doing it to make life easier (or cheaper) for you.
In future, people in the mainstream networking field (i.e. outside of the automation business) are developing standards for "QOS" (quality of service) for real time networking for things like live streaming video and audio (this is expected to become a very large market). As to whether the automation vendors will adopt this remains to be seen.
just a word on the "proprietary" discussion. PROFINET is as proprietary as Ethernet/IP or any of the other major Ethernet-based system. They are all defined in the same IEC specifications (e.g. 61158). So how more open can you be?
For the IEEE 1588 you need indeed hardware support for using this protocol in motion control applications. Otherwise you can't get the precision you want. I don't know if you can get them today in of-the-shelf products. I have not seen one yet, but sooner or later they will be out. Whether you will find these chips in a lot of Ethernet products is another question. You simply don't need them for most devices.
In reply to Karsten Schneider - IEC 61158 simply states that virtually all the major proprietary industrial protocols are "IEC 61158 compliant". In other words the standards process accomplished nothing in this instance which is of any interest to end users.
As for PROFINET in particular, I believe it is protected by at least four or five patents (if not more). If you go to the Profinet web site you will find that even the list of which patents are relevant is considered proprietary and only available to club members. The patents are there to ensure that the protocol would remain proprietary even if someone were able to reverse engineer the actual protocol.
Obtaining a standards number from an organisation does not make something non-proprietary. Many standards organisations simply rubber stamp whatever proprietary proposals are submitted to them and give them a "standards" number. Sometimes this is just a public relations exercise, as customers do look for standards (under the mistaken impression that this necessarily means non-proprietary). In other cases, the standards numbers are useful book keeping and labelling procedures for companies participating in patent pools or cross-licensing of proprietary technology.
With regards to IEEE 1588 in particular, this is simply a clock synchronisation protocol which is implemented in hardware (and so more precise than NTP). Profinet "real time" motion control applications however also reserve network bandwidth for critical communications. Network components used in Profinet real time applications require a special ASIC which is not present in normal Ethernet hardware.
None of the above is intended to imply that Profinet is "bad". It is however important for customers to realise that they are indeed buying devices from a proprietary product line.
I am sorry, but I don't see, what this proprietary discussion is good for in respect to the end user. He buys products from vendors. And in all the clubs there is always a selection of vendors. PI (the "club" for PROFIBUS and PROFINET) has more than 1300 members! That is a huge selection to choose from as an end user. Do you really want to call this proprietary?
The clubs offer the big advantage, that there is a group maintaining and improving the standard. Whether it is ODVA or PI, DeviceNet or PROFIBUS. These systems have continually advanced over time. This wouldn't happen without the "clubs". They make sure, that there is interoperability and some certainty for the end user, that the devices will work together. In this sense it is indeed important for a customer to know, that it is a "proprietary" standard.
Manager PROFI Interface Center
PROFIBUS & PROFINET Competence and Test Center
One Internet Plaza
Johnson City, TN 37659
phone: +1 423 262 2332
fax: +1 423 262 2103
Since my original post I have done some additional research on the protocols. First off, neither ProfiNet or CIP Sync/IEEE 1588 are truly open or non-proprietary in the strictest sense such as GNU or the Internet RFCs.
You can probably implement a non-commercial low accuracy software version of IEEE 1588 as was done here: http://ptpd.sourceforge.net/ . However, IEEE 1588 is covered by several patents as listed here: http://standards.ieee.org/db/patents/pat1390.html (see Std No 1588). I contacted Agilent, the patent holder, and found that they offer a royalty free, non-discriminatory license for a one time fee of $1000.
Of course, to implement the CIP Sync or Motion protocols you can only get the official spec by joining the ODVA "club." To get highest accuracy you have to use IEEE 1588 enabled (and Agilent licensed) Ethernet controllers in all end nodes and switches/routers. I guess the non-proprietary "hope" for IEEE 1588 is that it will someday be available in off the shelf switches and routers that are not specifically for industrial applications and, in turn, the general purpose IEEE 1588 enabled controller chips can be cheaply integrated into the industrial end nodes. However, this is not yet the case from what I can tell.
This compares to ProfiNet hard real-time which requires a special "ERTEC" chip (an ARM9 with a ProfiNet stack) in each node and switch. The chip is specialized for industrial applications and has no other use, AFAIK. It does a low level modifications to the Ethernet protocol to accommodate the real time features. It also uses a special protocol on top of the modified Ethernet instead of IP and UDP like IEEE 1588 uses. Of course standard TCP/UDP/IP can still be used, but with a lower priority, and does not affect the real-time channel performance.
Perhaps ProfiNet could be seen as more proprietary than CIP Motion/IEEE 1588. However, rather than relying on the hope for general purpose parts to materialize that implement 1588, ProfiNet directly attacks the problem using specially designed ad-hoc chips and protocols. And as a previous poster pointed out, the degree of "proprietary-ness" is probably not that important to end users. Instead, availability from diverse sources, price and performance are more important.
I am looking for a contact at Agilent regarding the licensing fees for the 1588 patents. Who did you talk to there?
The last figures I saw from Rockwell were:
- *WITHOUT* special MAC hardware to detect the 1588 PTP packets, they have demonstrated +/-100 usec
- WITH the special hardware, you get down to tens of nsec accuracy.
So it is really just depends on what you need - many drive apps are happy with multi-millisecond accuracy (ie: 1000+ usec). Others are not, but no point over-buying accuracy you don't need. There seems to be a lot of dread spread that motion requires 10 nsec or nothing.
There is an interesting core difference between the AB and Siemens approach. AB is assuming the modern drives have more than enough horse power to extrapolate drive commands given the shared system time that the motion points need to be reached, whereas Siemens seems to think it best the master controller do all the calculations and just slap
precalculated answers down on strict schedule. In the Ab world, the exact time commands arrive at the drive isn't important since the command in effects says "at X time, be doing Y" where as the Siemens approach is "now as you receive this start doing Y".
Both designs will work - AB's idea is new & thus a bit scary but functions on mixed device Ethernet while Siemens' idea is a very traditional notion of controller/drive relationship but adds some
scariness on the Ethernet side.
- LynnL, www.digi.com