Ethernet & Determinism

In the recent Personal PLC Tutor E-mail on FireWire (19Sep05) it is stated that (FireWire) "is deterministic... and that's a step better than Ethernet."

However, I thought Ethernet could be made deterministic through the use of Ethernet switches and full duplex communications.

pjm

No
Ethernet is not deterministic
Switches etc are good but will not give any quarantee

Maybe in the future...

Firewire is deterministic; Ethernet is not. USB is also NOT deterministic... this is why external DVD & CD burners actually have higher success rate using slower firewire than faster USB 2... But I digress...

In Ethernet comms you have no guarantee that your data will make it from A to B in any time frame. Depending on protocol you can guarantee that the data will make it, but not when. Ethernet is a very good choice for a lot of things because of the ultra high speed (compared to everything else available including firewire), but you need to make sure all the devices on the Ethernet network can handle the 'what if' of delays in data getting from A to B.

So how deterministic does Ethernet need to be to be deterministic?

I wouldn't use Ethernet to update drives or to read the feedback but Ethernet is now widely used in many industries as the prefered bus.

The main thing you want to have is full duplex Ethernet devices so a master can send and receive data from a slave device at the same thus avoiding colisions. The only time you will have collisions is when two masters want to talk to the same slave at the same time such as when a HMI is reading the slave device at the same time as the PLC reads the slave device.

So what happens when there is a colision? The retries happen much faster than the scan time of most PLCs so you will not see any delay anyway.

PJM, there are some deterministic versions of Ethernet but in general, Ethernet is not deterministic. The question I have for you is 'does it make any difference?'

Peter Nachtwey said:

there are some deterministic versions of Ethernet but in general, Ethernet is not deterministic. The question I have for you is 'does it make any difference?'

Click to expand...

Good point. Keep in mind that on an Ethernet network you can have what is refereed to as a Broadcast Storm.

A Broadcast Storm is simply when a device (or several devices) sends out a broadcast (message to all nodes) over and over again as fast as it possibly can. This can lead to very high collision rates for other devices trying to use the network.

A common source of a broadcast storm is a virus in a computer; another common one is an HMI with poorly designed or implemented communications.

Some industrial network switches protect against broadcast storms by only allowing any single port on the switch to be active 50% of the time; from what I've found very few switches have broadcast storm protection and the ones that do are very high dollar... I've also found that the high cost for a good industrial network switch with broadcast storm protection is worth every penny when you need near deterministic communications, but want to use Ethernet.

Use common sense, Ethernet will work.

marksji said:

Good point. Keep in mind that on an Ethernet network you can have what is refereed to as a Broadcast Storm.

A Broadcast Storm is simply when a device (or several devices) sends out a broadcast (message to all nodes) over and over again as fast as it possibly can. This can lead to very high collision rates for other devices trying to use the network.

A common source of a broadcast storm is a virus in a computer; another common one is an HMI with poorly designed or implemented communications.

Click to expand...

GIVE ME A BREAK. THE WORLD WILL COME TO AN END TOO. SO? Hopefully you will find a virsus scanner for the PC before that happens. Hopely the PCs are on their own network and can't interfere with the control networks. BOGUS argument.
Most of the Ethernet projects I am involved with use our motion controllers and Rockwell PLCs. They don't get viruses. Our motion controller will not cause a broadcast storm. It speaks only when spoken to unless it is in Ethernet/IP's Ethernet I/O mode where is multicasts at fixed intervals that you can set. Rockwell calls this produced data. A high end switch or router can be configured to limit where the multicasts go.

marksji said:

Some industrial network switches protect against broadcast storms by only allowing any single port on the switch to be active 50% of the time; from what I've found very few switches have broadcast storm protection and the ones that do are very high dollar... I've also found that the high cost for a good industrial network switch with broadcast storm protection is worth every penny when you need near deterministic communications, but want to use Ethernet.

Click to expand...

I have never heard of a broadcast storm with industrial devices.
I we have created overload net works at Delta which slowed down to a crawl but it was intential. I have had customers bog down their net works with many small packets instead of a few larger packets. I have seen people request very fast updates using EthernetIP's Ethernet I/O but I have never heard of flast based devices just send garbage over and over again on its own. Most I/O devices only speak when spoken to like our controller. Most small devices have only a 8 bit controller and CAN'T send enough traffic to bog down a network. A SLC can only do about one message every 28 milliseconds. A PLC5 about every 10. ENBT cards are much faster but you have control over the I/O update rate. Our new 100 MB Ethernet controller is MUCH faster than a ENBT card yet is still takes about .6 milliseconds to respond to a message. There is a lot of free time between the messages even with our controller.

Yes, one can overload a Ethernet network but you have to work at it. Most of my customer by multiple ENBT cards. One will run 4 or 5 of our controllers. One will hande the HMI and programming. One handle the scanning data. The last handles all the Ethernet I/O digital and analog devices. Each card is its own network so there are few collisions. How long will a retry take. Will a PLC even know a collision has happened?

I'm wondering aloud here....

Would it be fair to say that the use of switches (particularly managed switches) along with routers and full duplex comms do not provide determinism, but instead really just reduce excess traffic? All of these advances are really just bringing more efficiency to the network. As a result, this reduced traffic allows for a more timely, although not deterministic, response.

OG

Like Peter said, just be smart. If you don't try and break your network it probably won't break. If you don't open your network up to uncontrolled traffic, it won't have uncontrolled traffic.

Determinism is an nebulous thing. Ethernet is a physical meduium that SUPPORTS collision protection and mediation. That doesn't mean your Ethernet network MUST HAVE collisions. Like Peter said, as long as your devices support full duplex communication you reduce your chances of a collision significantly. And speed forgives alot of sins. If a collision does occur the retransmission take place so fast your chances of seeing the effect are pretty slim.

Keep in mind that alot of the things we are talking about are pretty far up the Ethernet ISO model. Don't blame the transport medium, blame the protocol. Two things that ControlNet has going for it is:
1) It won't let you schedule a network that gets you in trouble.
2) Unscheduled messages are broken up into small enough pieces that if a scheduled event occurs it gets the network relatively quickly.
ControlNet doesn't have a monopoly on that methodology.

As you can probably see, I'm an Ethernet fan. I've used it several times with both low-end and high-end components and have not had any issues either way. But microsecond jitter won't cause me any problems either. So how 'deterministic' do you need to be?

Keith

Common Sense? EXACTLY!

Peter, I'll admit that my experience is limited to the single industry (cotton ginning) and I know from reading your other posts that you have much broader knowledge and much more experience than I do, but...

Peter Nachtwey said:

GIVE ME A BREAK. THE WORLD WILL COME TO AN END TOO. SO?
BOGUS argument.

Click to expand...

I've been in the situation where a data logging computer with two network cards (one for computer network, one for control network) got a virus and started broadcast storming the control network. The computer was running anti-virus when it got infected, anti-virus software is not perfect. A network switch with broadcast storm protection saved my control equipment from having problems, but it was a common control network throughout the plant and not all other vendors used switches with broadcast storm protection; some of the equipment from the other vendors got quite upset at the network conditions. This was one of my first experiences with Ethernet and PLCs.

Peter Nachtwey said:

I have never heard of a broadcast storm with industrial devices.

Click to expand...

OK, here's one for your list...
I know of only one HMI that for a FACT creates a broadcast storm when talking to a PLC (or PLCs) via Ethernet. The AVG (also sold by AD) EZ-Touch WILL create a broadcast storm and use 100% of the network if it can. Obviously when there is only one EZ-Touch talking to one PLC on the network this is not an issue because, as you pointed out, Ethernet is faster than the PLC will respond anyway, but what if you have 7-8 PLCs, 3-4 HMIs all on the same network and all moving data between each other? I know that a broadcast storm that brings network response time from milliseconds to several seconds can happen; been there and done that.

Peter Nachtwey said:

Most of the Ethernet projects I am involved with use our motion controllers and Rockwell PLCs.

Click to expand...

If I ever come across a project where the only things that will ever be connected to the Ethernet network is your motion controllers and Rockwell PLCs then I guess I'll defer to your judgment that everything will be ok and I can use whatever network gear is cheapest and go on with life... I've never used your motion controllers (though I hear they are quite good) nor a Rockwell PLC so I can't speak to their reliability on a network.


------------------


With my last post I was simply trying to point out that in the real world things happen. Some idiot will connect an infected notebook to the control network, or some such stupid thing, and its better if the whole system doesn't come crashing down when things like that happen.

I guess my point was that while Ethernet is a wonderful communications network (I use it very expensively) you must put some careful thought and planning into what happens if (really more like when) the network bogs down AND what can you do to keep the network from bogging down.

Ethernet is not a secure network so anything can happen. Linksys makes a wireless router that has its firmware released to the public domain allowing users to get in and change the programming. Talk about a Pandora's Box!