Ethernet I/O errors

One question on all of this. You mention the din rail should be steel, not aluminium. How come; aluminium has better conductivity than steel?
Regards Alan Case
 
Not to throw a wench into this discussion what would ICMP sniffing do? I have it enabled on my ethernet switch?
 
allscott said:
So why again are we using ethernet for control? someone edumacate me please?

Uhhh... I can't.

I suppose, it is because as a networking standard, Ethernet is really The King (sorry Elvis).

From an actual 'Control' Standpoint, I despise the very thought of using Ethernet to control remote devices.

I accept (and even, lovingly use) Ethernet to talk between HMI's and process devices (well, PLC's), but I insist on having physical 'Line Start', 'Line Stop', 'Line Jog', 'Line Thread', 'Emergency Stop', and 'Emergency Stop Reset' buttons as a minimum.

I don't really care what managed N-TRON, or Phoenix, or Cisco switch people are using, unless they fully and completely understand the Ethernet (physical layer) protocols, they are asking for trouble. Ethernet is fantastic for setting up machine parameters, and 'tweaking' things, but it is still a long way away from being my choice protocol for actually controlling devices in real time.

Why?

How many 'Ethernet Only' advocets out there have ever heard of 'STP' ?

------------------------------edit---------------------------
I was going to describe what STP is, and what it does, and why it is absolutely essential if you rely on Ethernet for your systems control, but I'll leave that to the reader to research.

Let's see who answers correctly first :)
 
Spanning Tree Protocol
Plug a regular old unmanaged or even a managed switch with STP off & plug it into itself. The traffic will rebroadcast & kill THE ENTIRE UNMANAGED NETWORK. Major PITA.
 
Man, it's been a rough day!!

I thought I had a handle on STP, but apparently not. Given the Ethernet control topologies I've used I don't see where it would apply. I also don't see where it would be 'absolutely essential' unless one also takes the position that anything but redundant ControlNet is not a valid fieldbus system.

I've used Ethernet I/O successfully on too many systems to be convinced it can't work as a fieldbus. Granted, I'm not trying to do sub-millisecond control with sub-microsecond jitter. Just standard machine control with updated I/O every 10 msec or so. I tend to be a little careful on implementation but no excessively so. On the flip side I haven't had to do a 2000 I/O point system on Ethernet either.

I suppose some day I'll get bit, just like everyone else who's sworn off Ethernet. I had the same feeling about my first ControlNet project when I had to personally re-do all the cable connectors in the system. I stayed away from ControlNet for a while after that. But I'm back with ControlNet again. Eventually the same cycle will occur with me and Ethernet.

Keith
 
STP isn't as big of a deal as one would think, just don't make a looping system.

I prefer Ethernet, but then again, I'm young, I haven't ever lived without a computer, I know the hardware, I know the BASICS of managed networks, & I can run Cat5 cable like nobody's business.
 
Wow.. that was fast.
You Win CroCop!~!

And that is exactly the point. Most networks, even using relatively 'High End' switches, can't deal with a port on a given switch/hub plugged into itself. What happens, is that every single device on the connected network (if it's well behaved) see's a 'Duplicate IP Node', and shuts down it's traffic.

That is incredibly, (and almost awesomly) disasterous, as absolutely NOTHING will communicate with ANYTHING. Removing the short-circuit from the switch/hub will not cure this, as every (well behaved) device will have shut down it's Ethernet port.

It generally takes a complete reboot to re-establish communications.

Okay, so What is STP?

It is, correctly defined by CroCop 'Spanning Tree Protocol', but what is that?

Switches that incorporate Ethernet Level 3 (Spanning Tree Protocol) are designed so that the standard root/tree/branch method of resolving an address to a target are ignored. Instead, the switch itself, or in negotiating with other switches (that support STP) determines the 'Best Route From Sender To Target'.

In short, STP capable (and enabled) switches allow for 'Star Ethernet Connections' to be assembled into a 'Ring Ethernet Connecetion', and they disallow the loopback that occurs if you connect a switch to itself with a patchcord.

The problem is, many, many companies think that simple 'Managed Switches' will be enough, but they aren't. They are cheap, but will absolutely NOT protect from connecting one port on a switch, to another port on the same switch (or, even a different switch).

SNP capable switches essentially turn an Ethernet network into a 'Token Ring' network, which is inherently connected to itself. The only drawback, is that there is a bit of a lag when connecting to the network, as the switches themselves determine the best route to a host. The advantage? if properly configured, losing one connection to a host would result in a new connection being established, at the cost of a few seconds maybe.
 
So, to paraphrase, we don't like Ethernet because it's not idiot tolerant unless care is taken.

Single-point failures in DeviceNet will stop the whole network. Duplicate node addresses will upset ControlNet. A slip of a screwdriver on a drive can tear out a SERCOS cable and drop that network. If you inadvertently switch on too many of those handy terminators on Profibus modules the network will go down.

They all have their own little idiosyncracies that we need to deal with. That is, unless, we abandon fieldbusses altogether and go back to hardwired everything.

I agree that a properly laid out Ethernet network using the appropriate protocols will make a much more reliable system. But I still contend that you don't need to do anything particularly special with an Ethernet system in order to have a system that is as reliable and generally as high performance as any of the other filedbusses out there.

Keith
 
kamenges said:
They all have their own little idiosyncracies that we need to deal with. That is, unless, we abandon fieldbusses altogether and go back to hardwired everything.
Keith

If that ever happens I will hunt you down in the streets like a rabid dog just for jokingly mentioning it.;)

Fieldbusses are one of the biggest breakthroughs & most exciting aspects of PLCs IMO.
 

Similar Topics

Hi, I am dealing with a problem with a vendor that has gone unresolved for a long time. We have a slc 5/05 processor communicating over ethernet...
Replies
9
Views
2,252
I am using the ethernet module wizard in the Step 7 program giving the PLC an address of 192.168.0.21. My HMI runtime application on another...
Replies
2
Views
5,447
My problem of the moment (Well at least the one I’m hoping you can help with.) is. I have Allen Bradley SLC 5/05 Processors on an ethernet...
Replies
7
Views
36,847
Hello I have a s7-1200 and I would like to read the tags present in this controller with my controllogix controller. The two controllers don't use...
Replies
5
Views
168
Can we use a Simotion D455 ethernet port x127 as a gate, to access S7-1500 plc Tia Portal program ? In the Simatic manager, we used Netpro to do...
Replies
2
Views
93
Back
Top Bottom