Experience on fieldbus use...

R

Thread Starter

Rob Hulsebos

Hello list,

When we talk about the advantages of industrial networks, it is always done from the supplier side: savings on cabling, conduits, installation,
increase of flexibility, decrease of PLC rack size, etc. etc. etc.

Less is known about experiences once a system is installed and running.

Is maintenance going to be easier? Are problems less? Are new sorts of errors occuring? How quickly is the maintenance-staff 'upgraded' to
work with network-analyzers instead of voltmeters? Is the system more vulnerable to hw or sw problems? Is the complete system then 'down', or only a part of it? How easy is it to upgrade? Is the MTBF different? The MTTR?
etc. etc.

I'd like to hear of any "real-life" experiences with completed fieldbus-installations, either in the process or discrete manufacturing world. I'd also be very interested to hear about any reports written about this and available for the public.

To start with, here's one of my experiences: a user in a factory who had accidentally connected the 220V to the wires of a remote I/O network had
of course all (30) of his remote I/O modules burned out, and the PLC was thus in effect deaf and mute. That's the disadvantage of using with a network; had he used standard I/O modules with his PLC, only one I/O channel or perhaps one I/O board would have been damaged and his factory could perhaps been kept running in a degraded mode.

Greetings,
Rob Hulsebos
 
R
Recently I was working in the telecomms field, where apparatus must be able to stand up to
lightining strikes, in many locations it is a regular occurence. It is possible to do, but
industrial networks seem very poor on protection.

Next year, CE mark legislation will make 200V spike tesing on all I/O obligatory. This
could be interesting.

Much industrial net equipment does use opto isolators, generally speaking these will limit
the damage, but unfortunatly such isolators are on the 'main board' so you have to change
everything anyway. How about detachable isolators that could be changed like fuses?
 
A

Armin Steinhoff

>To start with, here's one of my experiences: a user in a factory who had
>accidentally connected the 220V to the wires of a remote I/O network had
>of course all (30) of his remote I/O modules burned out, and the PLC was
>thus in effect deaf and mute. That's the disadvantage of using with a
network;

I saw never such a situation in field ...
It can only happen if the network interfaces of the IO modules aren't optically isolated from the network media.

>had he used standard I/O modules with his PLC, only
>one I/O channel or perhaps one I/O board would have been damaged

That would also happen with a fieldbus module ..
To do a fair comparison ... you have to connect the parallel bus of the PLC backplane to 220V :)

Regards
Armin Steinhoff

http://www.steinhoff.de
 
J

Johan Bengtsson

Well....

The problems behave different, that's for sure.
If there are more or less of them is not as easily to say for sure. As long as you stay on copper you will always suffer from bad contact,
oxide, and other similar problems. Electrical disturbances from high power cables, radio devices, etc. is a problem with fieldbuses as well
as most types of analog signals. Opto will never suffer from electical disturbances, bad connectors and similar may still exist however.
A big difference is: the signal will never (that is, almost never) get from the sender to the reciever and be wrong. Either it gets there and
is correct, or it doesn't get there at all (CRC:s and such takes care of that, they may (and will) fail, but not very often). All failures of the bus operation is detectable and is able to rise an
alarm, the machine will probably not function too well until it is fixed Non fieldbus (ie discrete signals) is not as easily automatically
detectable for errors.

Analyzers definitely need education to be useful, they are often easy enough to use, but a long list of raw material will not mean anything to
the untrained.

About maintenance: most devices needing maintenance are the devices connected to the bus, not the bus itself, like valves and so on. This
kind of maintenance can be a lot better by the use of more "inteligence" in the devices (like reports similar to: "Hey! I am valve XYZ123 I am not broken yet, but quite soon (for example during the next planned stop) would be a quite good time for replacing me").


The top reasons for non working fieldbuses as far as we have seen include (not necesarily in any particular order):
Wrong use of terminating resistors
Bad connections
Bad configuration
Electrical disturbances

Wrong use of terminating resistors and bad configuration will of course not make the fieldbus fail after it once is started up correctly unless someone alters it. Most bad connections and connectors and electical disturbances are fixed during installation and the first time in use.

Conclusion: Maintenance staff will have other things to do, not necessarily either more or less. They need education. Most problems arise
during installation and first time in use.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
C

C. Thomas Wiesen

Just to be the devils advocate....

Say for instance a fork lift took a wrong turn and broke through a wireway with 100 I/O
control wires. Which would be easier to fix, 100+ unlabeled I/O wires or one color coded network cable and a few power leads?


C. Thomas Wiesen
Kukulu Automation
[email protected]
 
S
Rob:

We build alot of our own equipment, production lines, data collection systems, etc. We chose to use DeviceNet about a year ago and since then
have installed six different networks in two different plants. We control some analog I/O, A/B A.C. drives, and digital I/O on the networks. Other than some DeviceNet particular limitations such as cable length and speed, we have had good luck with it. It has almost cut in 1/2 the electrical install time, and has also enabled us to add I/O wherever we want. We did have some training issues in the beginning but once we overcome that,it has been smooth sailing since. I would strongly suggest to anyone to pursue remote I/O networks. I wouldn't necessarily suggest DeviceNet, everyone may have different requirements, but I do like the idea of putting the I/O on the machine. It's also nice to have the ability to by I/O devices from different vendors if the network chosen is an "Open" network.

Just my opinion.

Regards,

Scott Brown
Gemtron Corporation
 
A

Andre Leeuwis

Remember, with say 10 instruments on every segment it is not 100 but 10 wires you need to fix. And to be honest who experienced a problem like this before.

Regards,
Andre
 
J

Johan Bengtsson

Interesting...
You will of course get an universal solution by using fiber instead of copper...

200V? do you know for how long? energy? and do on... IT would not be THAT hard to make modules handling 200V for a short time....

I still agree with you that it is interensting how many of the current I/O:s that actually will handle it.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
R

Rob Hulsebos

Well I have done projects where this risk was considered to be high enough to warrant the investment of developing a redundant CAN-network just to handle this case (of having all wiring damaged).
 
R
>I saw never such a situation in field ...

I did. And, to add, fried chips & PCB's don't smell nice! (I had to remove those I/O blocks from my office).

>It can only happen if the network interfaces of the IO modules aren't
>optically isolated from the network media.

I think you are missing the point here. Those I/O module *had* optical isolation. However, the circuitry *before* the opto is not protected by it, only the components behind it. Thus, galvanic isolation or not, a small but essential part (the network interface) is damaged (burnt out, in my example). The galvanic isolation protects the
system behind it, but in doing so is usually sacrifised. Some people assume that galvanic isolation protects everything. I did indeed think this until this accident. Now I now better....

So what we had to do was to replace the transceiver boards of all I/O modules. The I/O circuitry itself and the network processor were undamaged.


>had he used standard I/O modules with his PLC, only
>one I/O channel or perhaps one I/O board would have been damaged
>That would also happen with a fieldbus module ..

No, because there is not a single point of failure here.

>To do a fair comparison ... you have to connect the parallel bus of the
>PLC backplane to 220V :)

This itself is not a fair comparison.
The discussion is about: what are the weak points of a bus against discrete I/O. You are stating 'a serial bus is not worse than discrete I/O, because a parallel I/O has the same drawback'. Parallel I/O is not of importance here. But indeed, one has to be careful when connecting power-supply wires to a running backplane... don't
have the power-supply lead accidentally touch the backplane... these things do happen too... nice fireworks with 40A supplies...

Greetings,
Rob Hulsebos
 
J

James Bouchard

We had a case where a mechanic drilled thru a square tube and also thru a one inch rigid conduit on the back side containing 50 control wires. Fortunately the power was off and no one was hurt but it took two shifts to pull the wire out, pull a new one in and redo the terminations. It does happen!!

James Bouchard
 
Top