Today is...
Friday, April 19, 2019
The OPC Community Forum.
The fieldbus of the future
(Originally posted Mon 10/19/1998) I think that USB (Universal Serial Bus) or something like that, will be the fieldbus for the future...
By Miguel A. Serradet on 11 November, 1999 - 5:20 pm

(Originally posted Mon 10/19/1998) Hello everybody:
I have a question for you.
I think that USB (Universal Serial Bus) or something like that, will be the fieldbus for the future. It is based on an open platform (the PC) that any one can provide products for it. This, joined to softwars standards like OPC and CORBA, will answer all our questions about industrial automation, due to the highest degree of openness that could be reached (for now on).
Does any one agree with me?
Mike.
Ing. Miguel A. Serradet
Dept. Automatización Industrial (DAI)
EC MINBAS
Habana Vieja, CP 10200
C. Habana. Cuba.

By Jeffrey Field on 11 November, 1999 - 5:23 pm

(Originally posted Mon 10/19/1998) I agree with you. I work for a large integrator, and we have developed our own object-based open control software which we are now using on 80% of our jobs. It is NT based, but can run on RTOS (QNX/CE) . It is based on the CORBA distributed object stardard. DCOM, Active X, and JavaBeans are also supported. It also has one common IEC-1131-3 standard programming interface for logic, robots, servos, etc. The open object standards and web-based technologies allow us to reduce programming by more than 60% and eliminate the SCADA middleware like Wonderware, Intellution, Factory Link, etc. Using a regular web-browser and JavaBeans the SCADA level is practically free (and way more connective).

Jeffrey Field
Applications/Marketing Manager
Advanced Automation, Inc.

By Ralph Mackiewicz on 12 November, 1999 - 10:55 am

(Originally posted Thu 10/29/1998)
>I have a question for you. I think that USB (Universal Serial Bus)
or something like that, will be the fieldbus for the future. It is
based on an open platform (the PC) that any one can provide products
for it. This, joined to softwars standards like OPC and CORBA, will
answer all our questions about industrial automation, due to the
highest degree of openness that could be reached (for now on).
Does any one agree with me?<

Not me. USB is no more likely to be adopted as a fieldbus than RS-232 or RS-485. It lacks application protocol standardization. RS-485 was not a suitable fieldbus until Profibus added the FDL, DP and FMS standards to run on top of it. CAN wasn't suitable until ODVA added DeviceNet protocols and so on. From what I can tell, the only protocols standardized by USB are for media applications and some low-level stuff to allow automatic matching of peripherals to the required drivers in the host system.
There are also numerous physical limitations of USB that make it unsuitable for fieldbus applications several of which have been previously posted to this list.
USB is an excellent system for integrated peripherals on desktop computers. It looks pretty poor for a fieldbus.

>I agree with you. I work for a large integrator,
...snip...snip... open object standards and web-based technologies
allow us to reduce programming by more than 60% and eliminate the
SCADA middleware like Wonderware, Intellution, Factory Link, etc.
Using a regular web-browser and JavaBeans the SCADA level is
practically free (and way more connective).

AND:
What are the requirements for a fieldbus:
...snip...snip...
3) Interface cost less than US$1.00?<

A dollar? Why should anyone have to pay a buck for an interface? The ideal fieldbus should require no installation, no prior knowledge, no configuration, no intelligence to operate and should be included free of charge with all instruments, computers and software applications. Come to think of it, let's make the instruments, computers and software applications free too! ;-)

Regards,
Ralph Mackiewicz
SISCO

Quote of the Day: "Connectivity alone is not enough for
interoperability. Application protocols are needed too."-Me

(Originally posted Mon 11/02/1998) I think the fieldbus of the future will be based on human factors as much as technical ones. The busy engineer has not time to research all the myriad fieldbuses out there, and will latch on to those that have highest profile. This profile will be a combination of perceived openness and acceptance by others. After that, technical issues will be examined.

(Originally posted Mon 10/19/1998) I'm new to the USB and would like to know how it is different from the old RS-232. Both in hardware and software. Where can we find more information on the USB?

By Art Bourdeau on 11 November, 1999 - 6:09 pm

(Originally posted Tue 10/20/1998) More information can be obtained at the following places:
http://www.teleport.com/~usb
USB Implementers Forum
JF2-51,2111 NE 25 th Ave
Hillsboro, OR 97124

Regards,
Art Bourdeau,
artb-applied@worldnet.att.net
Web Page
http://www.applied-controls.com

By Mark Chesney on 11 November, 1999 - 5:25 pm

(Originally posted Mon 10/19/1998) I do not disagree with you about the importance of software standards like OPC and CORBA, however, USB does not appear to be a viable fieldbus candidate. While the chipsets are inexpensive (which makes it very attractive), it was designed for use as a high-speed "desktop" bus with very limited cable lengths. This makes it unsuitable for use in a distributed application.

By Josué Portal on 11 November, 1999 - 5:31 pm

(Originally posted Tue 10/20/1998) What about ethernet?
Does anybody know something related with using ethernet as fieldbus?

By Rick Daniel on 11 November, 1999 - 6:08 pm

(Originally posted Tue 10/20/1998) Automation Research Corporation and lots of others think it's going to be Ethernet.

Rick Daniel
Intelligent Instrumentation
http://www.instrument.com

(Originally posted Tue 10/20/1998) I believe Opto-22 now has Ethernet I/O.

(Originally posted Thu 10/22/1998) Sixnet has ethernet I/O.

(Originally posted Tue 10/20/1998) Howdy Mike,

USB would be good, as long as your fieldbus didn't need to extend further
than 5 meters. See http://www.kavi.com/usb/developers/usbfaq.htm#longusb
What are the requirements for a fieldbus:
1) High speed
2) Deterministic
3) Interface cost less than US$1.00?
4) Inexpensive cable, less than ? per meter
5) Labor to install comm wire (in conduit), less than US$50.00 per meter?
What other factors do the list members consider important? Unpolarized, no topological restrictions?
If the labor to install the wiring is so high, why do we even consider the cost of the cable and interfaces?
Best,
B.O. Oct. 20, 1998
--
Robert Old, System Architecture, bob.old@us.landisstaefa.com
Siemens Building Technologies, Inc., Landis Division

By Rob Entzinger on 11 November, 1999 - 6:11 pm

(Originally posted Wed 10/21/1998) Is TCPIP not the route of the future ?.
I am under the impression 100MHz ethernet/TCPIP will be the fieldbus of the future.
It's cheap, widely used and every kid will know about it from the internet.
AND
With the right design (switches, hub and routers) will be "deterministic" (it will be so fast it can be classed as deterministic)
Rob Entzinger
Applications Engineer
Schneider Automation (PTY) Ltd South Africa

By Bennet Levine on 11 November, 1999 - 6:14 pm

(Originally posted Wed 10/21/1998) And once you add the cost of the 100BaseTX switches and routers your "cheap" system has grown significantly in price.
Bennet Levine
Contemporary Control Systems, Inc

By Josué Portal on 11 November, 1999 - 6:14 pm

(Originally posted Wed 10/21/1998) Fieldbus Foundation have announced the development of a new high-speed fieldbus based on ethernet, I'm not sure they will use TCP/IP as transport layer of the protocol. Any way, the new standard will be ready by the end of this year and I'm anxious by seeing the replies from the others fieldbus groups. I'm specially interested in to know everything related with the use of ethernet/TCP/IP as fieldbus and to determine if there are other standards technically feasible enough to be use as fieldbus and that they are so open and so cost-effective as ethernet.
I would appreciate any information of any kind.
Thanks
Josué Portal

By Armin Steinhoff on 12 November, 1999 - 10:20 am

(Originally posted Mon 10/26/1998) A PROFIBUS working group is already active for the design and standardization of PROFIBUS on ETHERNET. I'm not sure ... but I expect that they will introduce a token passing protocol instead of using TCP/IP.
Regards
Armin Steinhoff
http://www.steinhoff.de

By Randy Sweeney on 12 November, 1999 - 10:39 am

(Originally posted Mon 10/26/1998) if ProfiBus (read Siemens) chooses Token Ring (read dead technology) then
they will die
When will we learn that commercial technology has zoomed past us like we were standing still.
A superior commercial technology doubling every 14 months will eclipse anything optimized that we can generate in 14 years... this is unstopable... pure non-linear math.
I can not believe that Siemens will be so stupid as to oppose the inevitable...
Ethernet is and will remain the future until it is replaced by something else which will NOT come from factory automation.
Randy Sweeney
Philip Morris R&D

By Armin Steinhoff on 12 November, 1999 - 10:44 am

(Originally posted Tue 10/27/1998) At 22:16 26.10.98 -0500, you wrote:
>if ProfiBus (read Siemens) chooses Token Ring<

Sorry ... PROFIBUS is not a property of Siemens ! I don't know why the PROFIBUS should use Token Ring ?? PROFIBUS is based on a hybrid Token BUS protocol .....
[clip ... ]
>I can not believe that Siemens will be so stupid as to oppose the
inevitable... Ethernet is and will remain the future until it is replaced
by something
else which will NOT come from factory automation.<

I can't speak for Siemens ... but the PROFIBUS will run in a short time frame on ETHERNET !
Regards
Armin Steinhoff
http://www.steinhoff.de

By Andy Piereder on 12 November, 1999 - 10:47 am

(Originally posted Tue 10/27/1998) It is a mistake to say that a technology is dead. I think what you really mean is that token ring is obselete in terms of office LAN. In terms of industrial networks, token ring has advantages for determinism that are not easily overshadowed by other approaches.
New technologies rarely supplant older technologies completely, but rather provide a better solution in some cases, increasing the number of potential solutions for any given problem. The impression that an older technology is dead is usually the result of older technology being used problematically because no other alternative exists. The problems created at the limits of a technology's application is the impetus for the development of alternate solutions. Realistically, the new solution also has its limitations, and rarely if ever do those limits every coincide perfectly with the old technology.
Andy Piereder
Pinnacle Automation

(Originally posted Tue 11/10/1998) Try http://www.opcfoundation.org for more information.
José Chong
Field Instrumentation Support Eng

By Thomas Wuensche on 11 November, 1999 - 6:15 pm

(Originally posted Wed 10/21/1998) I'd agree that Ethernet may be a good solution on the higher layers, networking PLCs, PCs and other complex intelligent devices. It doesn't seem to be a good solu-tion for the sensor/actor level due to wiring restrictions. For the lower layers a bus like CAN or LON seems more appropriate. These networks are better adopted to the typical properties of the sensor/actor layer like small packets with realtime requirements from a large number of devices.
Best regards,

Thomas Wuensche

By C. Thomas Wiesen on 11 November, 1999 - 6:16 pm

(Originally posted Wed 10/21/1998) I have wondered about the merits of Ethernet used for an industrial network. It's fast, and studies have shown that it is deterministic at low load conditions. I think that using ethernet TCP/IP for industrial controls has several problems. First, the media and connectors are not industrial grade. The media will have to be developed/adopted and tested for industrial use. Second, more is required to carry out control than just ethernet TCP/IP. A communication standard needs to be developed to allow standard plug play components (I have heard that someone is working on using the foundation fieldbus (?) protocol over ethernet). Third, the theoretical problems with Ethernet make me think that it may not be suitable for future applications in the non-industrial sector where it is now king. One of the benefits of other industrial networks (such as DeviceNet.) are the daisy chain configuration and producer-consumer protocols. With the vast expansion of internet use, I could forsee bandwidth problems for future expansion of internet audio and video. All internet communications are point to point transmissions. This is grossly inefficient on a large scale when there are users that want the same data all over the world. Take for instance downloading of Netscape; a 17MB file that took me over 3 hours to download. Netscape has lots of servers that are occasionally overloaded in part because they are repeating 17 MB downloads to individual IP addresses (Millions of downloads). Imagine if a producer consumer network was created such that every 30 minutes on a regular basis, a new download of Netscape was sent over the Internet (if there were) any outstanding requests. Faster downloads, lots of money saved on servers for Netscape (and any significant download participant). Cost of internet services would decrease, services would increase. Imagine setting up a "Movie" server in your basement that services the world. Don't need massive high powered servers, just a high end box from Best Buy, video spigot, and a VCR. Not a bazillion point to point downloads, just one at a time. Subscribers would have a key to tap into the transimission. This could become quite a fantasy chain, but my point is that a point to point protocol has reduced benefit compared to existing industrial networks with protocols designed for robust, easy to change, minimal wire systems. My personal opinion is that these benefits that are in industrial networks will migrate (in the long run) to lare scale systems and not the other way around. Using eithernet for industrial control in my mind is like finding a way to make dump trucks cheap, nimble and fuel efficient. You still might not buy one for normal personal use even if it had better "Specs" than an economy car. Its just not designed for that. Just one of my crystal ball theories.... Would like to hear other responses to this thread.
C. Thomas Wiesen
University of Wisconsin-Madison
http://www.cae.wisc.edu/~wiesen

By Miguel A. Serradet on 11 November, 1999 - 6:20 pm

(Originally posted Thu 10/22/1998) Thomas Wiesen wrote:
>First, the media and connectors are not industrial grade.
The media will have to be developed/adopted and tested for industrial use.<

That can be easily solved. You have to do that for every
fieldbus you want to develop. Cards, cables, conectors can be created and
certified.
Industrial PC manufacturer are doing it right now. Thats not a problem.

Thomas Wiesen wrote:
>A communication standard needs to be developed to allow standard plug play components (I have heard that someone is working on using the foundation fieldbus (?) protocol over ethernet).<

Why did you say It's impossible to implement plug&play on Ethernet? High Speed Ethernet (HSE) is the next standard promoted by FieldBus Foundation as device level network.(Control & Instrumentation August 1998)

Thomas Wiesen wrote:
>All internet communications are point to point transmissions. This
is grossly inefficient on a large scale when there are users that
want the same data all over the world. Take for instance downloading
of Netscape; a 17MB file that took me over 3 hours to download.
Netscape has lots of servers that are occasionally overloaded in
part because they are repeating 17 MB downloads to individual IP
addresses (Millions of downloads).<

That can be a big problem IF you are in a point to point Internet comunication. But is not in a Local Area Network where Ethernet (I think) behaves like a multi drop comunication network; and at 100Mhz it is very, very close to a deterministic network. Besides, in an industrial field bus you dont need to transfer that huge amount of data, a few BYTES will be enough.

Ethernet is just like you have mentioned:
cheap, nimble and fuel efficient.

Thomas Wiesen wrote:
>My personal opinion is that these benefits that are
in industrial networks will migrate (in the long run) to large scale
systems and not the other way around.<

I believe that large scale systems (ethernet) will incorporate these benefits, and not the contrary. Ethernet satisfies our technical and economics requirement for the industry, and is so widely extended that seems imposible to me that actual industrial field buses (which are used only by a small sector of the potential users) be able to succesfully contest with such an opponent.
I would like to hear some opinions
Greetings
Miguel
Ing. Miguel A. Serradet
Dept. Automatizacion Industrial (DAI)
EC MINBAS
Habana Vieja, CP 10200
C. Habana. Cuba.

By C. Thomas Wiesen on 11 November, 1999 - 6:25 pm

(Originally posted Thu 10/22/1998) Thomas Wiesen wrote:
>>First, the media and connectors are not industrial grade.
The media will have to be developed/adopted and tested for industrial use.<<

>That can be easily solved. You have to do that for every
fieldbus you want to develop. Cards, cables, conectors can be created and
certified.
Industrial PC manufacturer are doing it right now. Thats not a
problem.<

Haven't seen any inexpensive washdown connectors for ethernet, do you have any information?

>Why did you say Its imposible to implement plug&play on Ethernet?
High Speed Ethernet (HSE) is the next standard promoted by FieldBus
Foundation as device level network.(Control & Instrumentation August 1998)<

Didn't say it was impossible, just not there yet. The evolution of any network, in market terms, has been a number of years after the network has become reliable and proven. The network may arrive, but with all of the other existing networks out there now, there will be a big lag before there is a multitude of input and output devices available.
Its obvious that there is momentum for putting ethernet in manufacturing controls, and I am not really opposed to it. I just think that there should be a better solution than modifying a system that is missing some key features that make industrial networks valuable strictly based on speed. I don't know exactly what that is.

Thomas Wiesen wrote:
>>All internet communications are point to point transmissions. This
is grossly inefficient on a large scale when there are users that
want the same data all over the world. Take for instance downloading
of Netscape; a 17MB file that took me over 3 hours to download.
Netscape has lots of servers that are occasionally overloaded in
part because they are repeating 17 MB downloads to individual IP
addresses (Millions of downloads).<<

>That can be a big problem IF you are in a point to point Internet
comunication. But is not in a Local Area Network where Ethernet
(I think) behaves like a multi drop comunication network; and at
100Mhz it is very, very close to a deterministic network. Besides,
in an industrial field bus you dont need to transfer that huge amount
of data, a few BYTES will be enough.<

Yes, and in the words of Bill Gates, "640K will be more than anyone needs". This is the exact reason for the evolution of the higher level control networks (Foundation Fieldbus, ControlNet, etc.). The bar is being raised for the amount of information and diagnostics provided in industrial networks. In a recent project that I worked on, the I/O count for the network was probably 3-4X what a point to point system would have been because the networked devices provided much more information. This system was mainly a discrete control system. Look at an HMI for a machine that is 15 years old (Button panel) compared to a similar modern machine with maintenance and help data available (touch screen) and compare the data transferred. And in the future when the operator interface for a purchased machine, and another HMI for a custom station, a UNIX box for MES, and a terminal to the site LAN (all in one location) are integrated into a single multi purpose unit. Lots of data.
I appreciate your response.

--
C. Thomas Wiesen
University of Wisconsin-Madison

By Thomas Wuensche on 11 November, 1999 - 6:26 pm

(Originally posted Thu 10/22/1998) Starting with your last comments: There are industrial fieldbus systems which have installed node count equal to the count of ethernet devices. Specially CAN comes to mind. Being used in automobiles, you'll soon have >10 CAN nodes in every new car. This means >5 CAN nodes per person in industrialized countries in the near future. CAN controllers integrated with a microcontroller are available below $3 in the correct volume today. However I would support your statement for the classic device level fieldbusses, here we can in fact observe the use of ethernet.
Regarding cabling: 100MB ethernet will not be usable as bus system on the sensor/actor level due to it's point-to-point wiring structure. You're not likely to connect a simple binary input over 100baseT to a hub. At least the idea was saving on installation cost through use of sensor/actor busses, and this would be difficult with 100baseT :-).
10base2, which would allow true network (line structure) installations, seems not appropriate due to it's wiring characteristics (or would you feel comfortable installing 10base2 with screw terminals on perhaps unshielded twisted pair).
Ethernet has better characteristics for long messages. Short messages are much better supported by specialized busses (like again CAN).
What I would see for future installations is a sensor/actor level bus for networking (intelligent) components on the sensor/actor level and above that ethernet on the higher levels. Instead of PLCs used now between the sensor/actor and the higher levels, gateways may be used between both systems.
Best regards,
Thomas Wuensche

By Michael Griffin on 11 November, 1999 - 6:29 pm

(Originally posted Thu 10/22/1998)
<clip>
Ethernet satisfies our technical and
economics requirement for the industry, and is so widely extended
that seems imposible to me that actual industrial field buses (which
are used only by a small sector of the potential users) be able to
succesfully contest with such an opponent.
<clip>

A number of the lower end industrial buses are based on CAN, which is actually an automotive network (i.e. used in cars). It was adapted for use in industry because it was cheap, rugged, and readily available. The automotive market is huge, so as this technology is more widely used the production volumes of CAN hardware may become much larger than the ethernet market.
Industrial networking may indeed adapt other commmercial systems to it's needs, but this doesn't mean that it will necessarily be the type of stuff you find on your desktop.

Michael Griffin
London, Ont. Canada

By Ralph Mackiewicz on 12 November, 1999 - 10:52 am

(Originally posted Thu 10/29/1998)
>I have wondered about the merits of Ethernet used for an industrial network. It's fast, and studies have shown that it is deterministic at low load conditions.<

Ethernet is not "deterministic" at any load condition. It is by design probabilistic. The real issue is performance. For many many applications Ethernet provides suitable performance even at higher load levels. The probabilistic nature is drowned out by the performance.

> I think that using ethernet TCP/IP for industrial controls has several problems. First, the media and connectors are not industrial grade. <

This is true in some respect as far as the connectors go, although this is also one of the reasons that Ethernet does not cost so much. The media itself is twisted pair wiring and you can get this cable with a variety of jackets on it for many different application requirements. I think that there are also companies that sell ruggedized Ethernet (Siemens for one). But then there is that nasty cost issue again.

> Second, more is required to carry out control than just ethernet TCP/IP. A communication standard needs to be developed to allow standard plug play components<

Yes. Very true. If everyone understood this, there would be fewer incompatible proprietary protocols and more open standards based protocols.

> With the vast expansion of internet use, I could forsee bandwidth problems for future expansion of internet audio and video. All internet communications are point to point transmissions. This is grossly inefficient on a large scale when there are users that want the same data all over the world. Take for instance downloading of Netscape; a 17MB file that took me over 3 hours to download. Netscape has lots of servers that are occasionally overloaded in part because they are repeating 17 MB downloads to individual IP addresses (Millions of downloads). Imagine if a producer consumer network was created such that every 30 minutes on a regular basis, a new download of Netscape was sent over the Internet (if there were) any outstanding requests. Faster downloads, lots of money saved on servers for Netscape (and any significant download participant). Cost of internet services would decrease, services would increase. Imagine setting up a "Movie" server in your basement that services the world. Don't need massive high powered servers, just a high end box from Best Buy, video spigot, and a VCR. Not a bazillion point to point downloads, just one at a time. Subscribers would have a key to tap into the transimission. <

This is an interesting scenario but it won't work for this particular application because your particular situation of waiting 3 hours for a download is not an inherent flaw in the system. It is with your Internet connection. I wouldn't want to wait 30 minutes to get Netscape. Using my connection at home it took me less than 5 minutes to get Netscape Communicator as I recall (I have a cable modem hookup to the network). The answer to this particular problem is bandwidth. However, there are Internet technologies being developed that will support an architecture very similar to what you are describing. Its called "push" technology. Some of the variants involve multi-casting data to multiple sources simultaneously.
Also, the approach you describe will push the cost of supporting millions of downloads from Netscape to the network providers. Given that I pay for part of the network, I would rather see Netscape take the hit than me.

> My personal opinion is that these benefits that are in industrial networks will migrate (in the long run) to lare scale systems and not the other way around. Using eithernet for industrial control in my mind is like finding a way to make dump trucks cheap, nimble and fuel efficient. You still might not buy one for normal personal use even if it had better "Specs" than an economy car. Its just not designed for that. <

I don't see many of the technologies specific to the industrial world making it to the big time of computer networking. Lets face it: what we do in the real-time/control area is a niche. The requirements that drove the development of DeviceNet, Foundation Fieldbus, Profibus, MMS, etc. don't exist in the world of banking, insurance, home entertainment, etc. However, there are some technologies of these other systems that can be applied effectively into our niche. This has been proven countless times (e.g. Ethernet, PCs, Windows, etc.) It doesn't matter how cheap dump trucks become. Hardly anyone has a need to own one. The requirements for a dump truck are radically different than the requirements for a passenger car. The cost of a dump truck is an effect of that difference, not the cause of the difference. Or, in other words, the cost of a dump truck is not the primary reason to buy a passenger car. Using Ethernet for industrial control is different. There are numerous applications where the particular characteristics of Ethernet can be used to build cost-effective real-time control systems.
Best Regards,
Ralph Mackiewicz
SISCO, Inc.

(Originally posted Fri 10/30/1998)
>>I have wondered about the merits of Ethernet used for an
industrial network. It's fast, and studies have shown that it is
deterministic at low load conditions.<<

>Ethernet is not "deterministic" at any load condition. It is by
design probabilistic. The real issue is performance. For many many
applications Ethernet provides suitable performance even at higher
load levels. The probabilistic nature is drowned out by the
performance. ...<clip><

I believe there are many ethernet based networks in the so-called "Rugged industrial LAN" arena; some have been working for several years.
FDDI is the TCP/IP backbone technology that I understand will give you determinism. But when you get off FDDI to Ethernet it becomes nondeterministic. Dual redundant networks can now be offered with off-the-shelf hard and software, and I think you will find many network solutions companies which have cut their teeth in the IT area willing to apply their expertise to the so-called industrial process control areas.

By Ralph Mackiewicz on 12 November, 1999 - 12:11 pm

(Originally posted Mon 11/02/1998)
>I believe there are many ethernet based networks in the so-called
"Rugged industrial LAN" arena; some have been working for several years.

FDDI is the TCP/IP backbone technology that I understand will give you
determinism. But when you get off FDDI to Ethernet it becomes
deterministic.<

FDDI is a 100mb/s fiber technology that uses a token passing scheme to acheive determinism. Bridging FDDI to Ethernet will not make Ethernet deterministic. Ethernet is still probabilistic. The issue that pertains to industrial applications is that Ethernet's performance is so high that its probabilistic nature is completely irrelevant for most applications.

>Dual redundant networks can now be offered with
off-the-shelf hard and software, and I think you will find many network
solutions companies which have cut their teeth in the IT area willing to
apply their expertise to the so-called industrial process control areas.<

This may be true, but some caution is needed. Putting together a network in a mainstream IT environment is considerably different from doing this on the plant floor due to so many factors that I could not possibly list them all in a single post. The technologies used may be the same but the applications are very different. You need to have an understanding of both to be effective.
Regards,
Ralph Mackiewicz
SISCO, Inc.

(Originally posted Tue 11/03/1998) Yes, I agree that the received wisdom appears to be that you don't mix an IT LAN with an industrial LAN, which I think is what you mean. Gurus and consultants all carry the same message - keep them separate. (see article in the US magazine "Control of the Process" Feb 1998 by Caro and Mullen entitled "Ethernet as a control network"). This means that a new niche is opening up in the industry. Some LAN system designers/suppliers are now offering their services for the so-called "Robust Process LAN". This is a LAN separate from the IT LAN, but bridged into it to allow certain authorised traffic.

By Hugo Rumayor on 14 December, 2001 - 11:34 am

Ethernet is not "deterministic" at any load condition. It is by design probabilistic. The
real issue is performance. For many many applications Ethernet provides suitable performance even at higher load levels. The probabilistic nature is drowned out by the performance.

Well you could use full duplex, and a good switch and determinism is close to real. There
are no collisions so you have all the bandwidth twice because of full duplex uses both lines at
the same time. And a good switch is able to forward packets in real time with minimum latency.
The problem is that most plc interfaces dont support full duplex.
There is also the concept of Quality of service
where a router makes decisions on what packet has greater precedence over others on a network making it more deeterministic on high loads.
It seems that these features will be incorporated to the switches on a near future.

> I think that using ethernet TCP/IP for industrial controls has several problems. First,
the media and connectors are not industrial grade. <

Right the connector must be changed, The cable used must also be changed to a shielded one
of greater quality.

By Philippe Dallemagne on 18 August, 2000 - 9:10 am

> Is TCPIP not the route of the future ?.
> I am under the impression 100MHz ethernet/TCPIP will be the fieldbus of the future.
> It's cheap, widely used and every kid will know about it from the internet.
> AND
> With the right design (switches, hub and routers) will be "deterministic" (it will be so fast it can be classed as deterministic)

I would like to agree, but this last sentence can not be taken seriously, IMHO. Speed and determinism are independent (read "orthogonal") properties. One does not change the value of the other. Of course, in some low-traffic applications, Ethernet can behave correctly.

(Originally posted Fri 10/23/1998) Hi !
I just returned from the ISA Houston show, the big hit of the show was
the
"Super Bus" or IEEE 1451, HP was showing a system running on off the
shelf Ethernet that had the ability to Syncronise the NCAP's (Network
Capable
Application Processors) to within 200 nano seconds, not a miss print 200
ns
Checkout HP's Industrial ethernet site at www.hpie.com
A survey was taken at the show and the following question was asked
"What final standard for a control network have you installed, intend to
install,
are leaning toward, or wish you had installed?"
The answer for North America and Outside North America :
Ethernet 26% 9%
Serial port 4% 2%
IEEE488 0% 0%
4-20ma 8% 4%
HART 3% 0%
DeviceNet 4% 0%
Interbus-S 0% 1%
Profibus 1% 6%
Foundation Fieldbus 8% 17%

Doug Smith
DougSmith@thegrid.net

By Armin Steinhoff on 12 November, 1999 - 10:23 am

(Originally posted Mon 10/26/1998)
>I just returned from the ISA Houston show, the big hit of the show was
the "Super Bus" or IEEE 1451,<

IEEE1451 is a family of draft standards since several years and does not define a "Super Bus".
It is a "distributed model for field devices" which can be used for different types of networks.

>HP was showing a system running on off the shelf Ethernet that had the
ability to Syncronise the
NCAP's (Network Capable Application Processors) to within 200 nano
seconds, not a miss print 200ns<

Impressive .... what was the network extension ?
Regards
Armin Steinhoff

(Originally posted Mon 10/26/1998) I find the 200ns time synchronisation on by HP on Ethernet very interesting as this time represents two bits on the original Ethernet and about 200 feet of cable on any network. Thus, to synchronise to this accuracy means adding in time at the moment of sending (to avoid the collision delays) and clocking this time at the moment of receipt as well as cable propagation delay correction. Or did I miss something?
If one wants to synchronise to this level or better one can also use GPS receivers.

(Originally posted Tue 10/27/1998) The big remaining percentage 46% for North America and 61% for Outside North America represent what kinds of control networks? Digital I/O or each company has its own protocol ?

(Originally posted Tue 10/27/1998) I suspect what is really represented there is 54% of the respondents were inside North America and 39% were outside North America. The other 7% would then be none of the above and rounding error.
But I probably should wait and see what Doug Smith's (no relation) response is.
Rufus

By Frank Tambone on 8 February, 2001 - 8:48 pm

Doug: Do you have any information regarding the cost of individual node installation and startup for each of the solutions? Could you help? Thanks Frank Tambone

By Murry Shohat on 12 November, 1999 - 11:54 am

(Originally posted Fri 10/30/1998) The other new PC-based bus with potential for control is Firewire or IEEE1394. One company, ORMEC, is taking a stab at using Firewire for motion control-see the story at http://www.ormec.com/mktdocs/servwire.htm.
This thread raises an opportunity to discuss development issues and impediments toward use of any PC-based technology for network control. What do list members consider to be the major developmental stumbling blocks?
For example, does a new connector need to be invented before 100base Ethernet can survive as a control network?
Does a software house (like Softing) need to develop and offer protocol stacks for each candidate interconnect?
It would be fun to compile a list of impediments. Please contribute, and
thanks
Murry

By C. Thomas Wiesen on 12 November, 1999 - 11:58 am

(Originally posted Fri 10/30/1998) Robustness of operating systems for Intel platforms
Control software for intel platforms (Robust, modular, convertible, standard(?)
Guarantee of non obsolescence of operating systems and control software for 10-20 years (Like PLCs).
I don't want to have to upgrade my machine controls (Hardware, software, operating system) just because there was a different reason to upgrade my desktop. Scenario: 10 years down the road the hard drive crashes on my PC based machine. Original control software is long since lost. Control software vendor no longer has old version of Control software to E-Mail me but would be happy to E-mail me the newest version for a big fee. I get the new software but it requires the newest operating system (for a small fee). A replacement hard drive cannot be found for this 10 year old PC and since the motherboard cannot support the newest operating system, I have to get an entirely new PC (for a moderate fee). Now with the new PC, operating system, and control software, will the 10 year old program be able to be run on the new control software? Even if it does, how long is my machine down? PCs are to PLCs like dog years compared to human's. I have already found this glitch. 6 year old PCs running test stands had to have monitor replaced because the once $100 CGA board, now dead, could not be replaced; had to replace the monitor and add VGA board. I don't remember but I think that programming had to be done to get the screen looking the same.
I believe that PCs are good when a great deal of functionality is required. Extensive HMI, on line help, massive diagnostics, very high I/O count, number crunching of data, data transfer, etc. For simple systems, PLCs fit the KISS principal and probably have a lower overall ownership cost.

>For example, does a new connector need to be invented before 100base
Ethernet can survive as a control network?<

Uhhhhh... YES. Having lots of different connectors adds cost. So connectors chosen need to cover the spectrum of all uses (in panel to wash down, to high temp)

>Does a software house (like Softing) need to develop and offer protocol
stacks for each candidate interconnect?<

A protocol standard and device profiles need to be developed. Sounds like other field busses are trying to migrate existing standards to ethernet. That will be interesting to se how that evolves.

Good questions.

By Ralph Mackiewicz on 12 November, 1999 - 12:29 pm

(Originally posted Mon 11/02/1998)
>This thread raises an opportunity to discuss development issues and
impediments toward use of any PC-based technology for network control. What
do list members consider to be the major developmental stumbling blocks?
...snip...
It would be fun to compile a list of impediments. Please contribute, and
thanks<

It would be interesting and useful to know this certainly. Knowing these tradeoffs is critical to being able to use this technology.
Connectors come to my mind as it pertains to Ethernet. Standard Ethernet connectors must be well protected.
But, if we answer these questions from the perspective of control and automation, we'll probably end up with a description for something like FF, Profibus, DeviceNet, ASI, etc., not Ethernet and the Internet. By letting a mass market (driven by the demand of many millions of nodes per year) answer these questions instead we get a very low cost high performance network. There will be tradeoffs in the use of a technology developed for this mass market for industrial applications. But aren't the tradeoffs necessary?
Regards,
Ralph Mackiewicz
SISCO, Inc.

By Thomas Wuensche on 12 November, 1999 - 12:34 pm

(Originally posted Mon 11/02/1998) If you look at CAN (the base for DeviceNet and CANopen), you have the best of both worlds. Developed for automotive applications, CAN is rugged and reliable enough for industrial applications and still has the benefits of a system used in many million nodes a year. The price of a CAN controller integrated within a microcontroller is below US-$ 1,00, and CAN controllers are available as on-chip peripheral from 8-bit controllers up to 32-bit RISC machines.
Furthermore CAN can be used either with a range of connectors or as pure wire fixed in screw terminals - choose what your application needs. Would you want to do that with Ethernet?
Best regards,

Thomas Wuensche

By Andy Piereder on 12 November, 1999 - 12:45 pm

(Originally posted Thu 11/05/1998) I had to chuckle when I read the subject line. Shouldn't we concentrate on a fieldbus of the present? While fieldbuses have made good inroads into automation, I find that most of the system integrators and end-users I talk to are oblivious, some dimly aware and all leary of this 'new-fangled' technology.
Before we start worrying about the technical what's next, we should insure that we have a market for 'what's next'....
Andy P.

By Dieter Montanez on 17 June, 2000 - 2:12 pm

I think that plain ethernet will be the "fieldbus"
of the future (if something like this will still be necessary). We do already run several power plants all of them intra en extra wired using ethernet topologies (copper, fiber wnd wireless). At the "field level" we use OPC and MMS/UCA protocolls for control intercomunication. At the interplant and corporate level we run plain TCP/IP for SCADA and ERP and CMS integration.

I agree with Andy P.....What about the FieldBus of the Present?

Take a look at the I/O vendors out there today. Especially ones that aren't directly associated with Allen Bradley or Siemans. Ask yourself what is the common thread in their Fieldbus offerings, and I think you will come up with CAN as the answer. Whether its DeviceNEt, SDS,Canopen, or whatever, they all have CAN chips, connectors, & protocol. In the spirit of this venue, if I was going to bring a Soft PLC to the marketplace, I would first ask "what hardware is available off the shelf?".

Hardware Vendors like Applied Data Systems and others already offer great Linux ready platforms with 2 CAN channels standard.

CAN is plenty fast for any DIO or analog devices. Motion Control can be handled via intelligent devices that have either direct motion capability or are their own producers on some mega network like Firewire.

Leave the HUBS and Switches for Peer-to-Peer Communications!!!!!!!

By Peggy Van Walle, ING on 20 December, 2001 - 11:36 am

I work in Europe. And here there are 2 types :
1. Profibus DP and PA
2. Eternet.
I believe that Etehrnet will be the future. We see more and more Ethernet in the industry. Also becauwe you can use FO wich has no problems
with EMC, which is here very important.

I have a question for you.
I think that USB (Universal Serial Bus) or something like that, will be the fieldbus for the future. It is based on an open platform (the
PC) that any one can provide products for it. This, joined to softwars standards like OPC and CORBA, will answer all our questions about
industrial automation, due to the highest degree of openness that could be reached (for now on).
Does any one agree with me?
Mike.
Ing. Miguel A. Serradet
Dept. Automatización Industrial (DAI)
EC MINBAS
Habana Vieja, CP 10200
C. Habana. Cuba.