Talk:Fieldbus

Rewrite
I updated and enlarged the standard section and removed all parts which are now redundant. Give me some time to go through the other sections...--Felser (talk) 14:00, 11 May 2020 (UTC)

The Article used to describe specifically the FOUNDATION fieldbus. I did the following: --BjKa 08:55, 25 August 2005 (UTC)
 * Incorporated the information from fieldbus control systems
 * Requested fieldbus control systems for deletion
 * Wrote an introduction
 * Added some standards.
 * Moved the Information that was peviously here to FOUNDATION fieldbus

The complete article is outdated. Is it possible to have an expert refresh it?

I agree fully. The article is to say the least outdated. The german wiki artikle de:Feldbus is significantly better and could be a good base if translated. I'm even willing to translate it, but replacing the whole article is something I'm hesitant as I'm relatively new at the en-wiki --Kramer-Wolf 09:33, 26 February 2007 (UTC)

I have changed the formating a bit to look more formal and moved some of the sections around. I'm willing to help out with the structure if Kramer-Wolf translates the page from German. The page could be updated section by section. By adding a 1 new section at a time. Existance is a struggle between life and death. I just like to watch. 17:15, 1 August 2007 (UTC)

Field bus
Isn't the generic term really "field bus" rather than "fieldbus"? Also, this page seems to be describing just one instance of the generic concept of a field bus. The Controller Area Network bus would be another example of a field bus. Unfortunately, I'm not an expert.

Correct -> it should read field bus Kramer-Wolf 09:26, 26 February 2007 (UTC)

Made a significant number of edits relating to current position (2007)

Neither am I an expert, but in modern usage (ca. 2012), the term fieldbus, or 'field bus', is rarely ever used to describe a specific standard, be it an officially sanctioned and recognized one, or any other specific standard or design. In fact, I would argue that the use of the term carries with it an implied meaning of generality. When one says, for instance, 'data are acquired from sensors via a fieldbus', it tends to imply that there is some generic form of interface that makes the specific type of fieldbus irrelevant.

I am not sure that there ever was a standard of any sort that described a protocol 'fieldbus', but if there was, I have not heard of it being used in many years. If there was indeed such a standard, I think modern usage of the term deserves as much space in the encyclopedia as the existing entry. There should also be a reference to the entry describing the generic use of the term. The distinction between modern usage and the official standard should be explicitly stated. TheNbomr (talk) 16:26, 19 August 2012 (UTC)

Different?
What is the unique difference between field bus technology and regular buses and computer networks? --Abdull 14:13, 11 March 2007 (UTC)

With field busses, the environmental part is far more a focus, while the physics of communication is often "old fashioned". There are often precise specs about wiring, connectors, network structures, diagnostics, automated tests for the devices, protection levels. Remember: The field busses were the first multi vendor communication systems, even though there (still) is typically one big player with each of the systems. That's one of the reasons why there are so many of them. Kramer-Wolf 08:31, 14 March 2007 (UTC)

Disadvantages - noise
I was under the impression that in general, digital signals are less susceptible to noise than analog, because any amount of noise will affect the transmitted analog signal, whereas digital signals are only affected if the magnitude of the noise is comparable to the quantization level of the signals. Why would this be different for field bus? 192.75.48.150 20:51, 30 April 2007 (UTC)

To my experience and theoretical background as well you are quite right. Some explanation never the less: In some applications it does not matter to have a temporarily wrong analogue value, while a detected wrong digital value causing a communication break down is unacceptable. So especially systems with slow cylce rates (seconds or so) and high availability requirements still favour analogue systems in some respect. All others certainly live much better with digital communication and error detection/correction mechanisms. Kramer-Wolf 07:28, 2 May 2007 (UTC)

The difference in this case is that the signal that is used is not a voltage signal, but instead is a current signal. It is much more difficult to affect a current signal, since the magnetic field, that typically greatly affects a voltage signal, generally does not have enough power to affect the current signal for a significant amount of time. --Existance is a struggle between life and death. I just like to watch. 17:20, 1 August 2007 (UTC)

Device power on Ethernet claim ?
In the article: "Currently the issue stopping most Ethernet fieldbus implementations is the availability of device power. Most industrial measurement & control devices need to be powered from the bus and Power-Over-Ethernet (PoE) does not deliver enough."

First of all, most of the traditional fieldbusses do NOT supply bus power. Only DeviceNet and ASI, and perhaps one more fieldbus can supply bus power. The highly popular profibus does not. So I do not agree that the availability of bus power is what is limiting Ethernet acceptance. Secondly, Power over Ethernet can deliver 13 Watts of power. This is more than enough for any bus powered field device. So even the second claim that PoE does not deliver enough is simply false.

I would say that Ethernet acceptance is more likely limited by the higher higher prices, the impractical star-structure of Ethernet networks, limited availability of field devices with Ethernet support (Profinet IRT, EtherCAT, Powerlink), questionable determinism (Ethernet/IP, Modbus, Profinet IO), questionable reliability under harsch conditions (RJ45 is certainly not the most rugged connector on the market, and rugged alternatives are typically not standardised).

Did you know that the modern 100Mbit Ethernet/IP and Profinet IO protocols are actually slower than their old 5Mbit/12Mbit predecessors, ControlNet and Profibus? Brolin 00:48, 7 July 2007 (UTC)

Full ack to Brolin, I removed the claim about insufficient PoE. In my opinion the only thing stopping ethernet based fieldbus from replacing the traditional ones is that the traditional ones are good enough for many applications, and there is no reason to touch a running system. Notan —Preceding undated comment added 11:57, 4 December 2009 (UTC).

Fieldbus Organization at Present
USA : [www.fieldbus.org] Middle East :[www.feucme.org] Australia :[www.fieldbus.org.au] Iran : [www.fieldbus.ir] —Preceding unsigned comment added by Mrazmara (talk • contribs) 13:02, 1 January 2009 (UTC)

FEATURES table editing
There are a number of issues I noticed in this table, which I believe need to be added or corrected. I can volunteer for this task. The issues are:

- No entry for FOUNDATION Fieldbus - Profibus DP cable redundancy claim: This is at best an option, not a standard feature for this protocol. - Profibus DP sub-millisecond cycle: Even at 12 Mbaud the typical performance of a Profibus DP is a few milliseconds. I have seen segments with less than 1 msec full-cycle but just barely, when using very few nodes and very short IO connections. But for practical purposes I find this claim too optimistic. — Preceding unsigned comment added by AlfredoMQuintero (talk • contribs) 03:10, 3 February 2011 (UTC)

I can only agree with you about Profibus. Redundancy support on Profibus is extremely rare, and Profibus is typically not used where sub millisecond performance is needed. Brolin (talk) 21:45, 22 February 2011 (UTC)

I do not believe Foundation fieldbus supports synchronisation. I for one have never heard of a motion control servo drive with Foundation fieldbus. I changed that entry in the table to "no" for now. Brolin (talk) 20:35, 25 March 2011 (UTC)

Disadvantages editing
There are some instances in which fieldbus components are not different in price, namely Beckhoff components. The internal bus of a Beckhoff PLC is EtherCAT so all of their components are already technically on a "field bus," whether they are directly attached to the PLC itself or not. — Preceding unsigned comment added by 134.79.222.200 (talk) 17:38, 14 May 2013 (UTC)