Forums.MrPLC.com: RIO to Ethernet IP conversion - Forums.MrPLC.com

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

RIO to Ethernet IP conversion Rate Topic: -----

#1
User is offline   JeffKiper 

  • Sparky
  • PipPipPip
  • Group: MrPLC Member
  • Posts: 437
  • Joined: 01-May 07
  • Location:Southern IN
  • Interests:Family
  • Country:United States
    United States
OK I have several drives on AB RIO. We are looking for replacements I am thinking Ethernet IP for comms. So how do I compare RIO token ring to EIP speeds?
I asked my local AB tech support and he said let the EIP run as fast as it can. I really liked that technical answer. I think my 4 year old could have offered that.
JAK

"Nothing counts as much as blood. The rest are just strangers"
0

#2
User is offline   Arlen Jacobs 

  • Sparky
  • PipPipPip
  • Group: MrPLC Member
  • Posts: 16
  • Joined: 21-May 09
  • Gender:Male
  • Location:Milwaukee, WI
  • Country:United States
    United States
I am not an expert in networking, but here is how I understand it...

If, you are talking about the exact same data (blocks of addresses) to the same PLC with the same ladder logic, then the theoretical values look something like this:

Data Rates
RIO 230,400 baud (in this case, equals bits/per second)
EIP 100,000,000 bits/second
EIP is ~ 434 times faster in data transfer than RIO (bits per second).

But in the real world, it doesn't quite work like that. Ethernet packets have overhead (TCP/IP) to help route packets to right place, and error checking, etc. Making a wildly conservative estimate, let's say that you only get 25% of the bandwidth for actual data transfer. That still makes EIP about 100 times faster than RIO, for a single point to point communication line.

Network Bandwidth
Like talking on the telphone to a friend, it doesn't work well when both talk at the same time. You have to share the line.

If you daisy chain devices (more than a total of 2), then any RIO device added starts to eat up some of that bandwidth. Token ring "passes" the authority on to who can talk at that time.
ex. Device A talks to Device B
When Device C talks to Device D, it takes available network bandwidth from Device A and B. Communications from A to B would never realize the full 230,400 data rate.

With ethernet, if you use a router it can separate traffic between devices/ports. Only traffic to common devices would go on the same wire (ex. multiple HMIs talking to a single PLC. The PLC enet link would see all the traffic on one line, but each HMI would only see its own traffic, filtered out at the router).
ex. When Device C talks to Device D, it does not take away network bandwidth from Device A to B communications (assuming the router can keep up to the packet rates)


From the installations that I have seen, I have not seen data requests alone exceed the 100mb/s bandwidth limitation on ethernet. Usually some other device reaches its limit before the network bandwidth limit is reached (ex. PLC CPU [comms vs. ladder logic], communication card, router, etc).
But I have often seen installations that reach the limits of RIO networks, where device and data blocks are high in volume.

Hopefully that is what you were looking for.
0

#3
User is offline   paulengr 

  • Propeller Head
  • PipPipPipPipPipPip
  • Group: MrPLC Member
  • Posts: 1,416
  • Joined: 27-March 05
  • Gender:Male
  • Location:North Carolina
  • Country:United States
    United States

View PostJeffKiper, on Mar 9 2010, 11:20 PM, said:

OK I have several drives on AB RIO. We are looking for replacements I am thinking Ethernet IP for comms. So how do I compare RIO token ring to EIP speeds?
I asked my local AB tech support and he said let the EIP run as fast as it can. I really liked that technical answer. I think my 4 year old could have offered that.


In a word, there's no comparison. If we turn back the clock to the early days of Ethernet (80's), there were two network standards out there, IEEE 802.3 and 802.2 (Arcnet, aka Controlnet). Arcnet was token ring running at 5 Mbps. Ethernet was 10 Mbps. Full duplex Ethernet didn't exist yet so it was limited to 3 Mbps with maximum tolerable latency and jitter.

Arcnet virtually disappeared over time (sans AB's holding onto it via Controlnet) for a couple reasons. First off, the NIC cards were roughly 20 TIMES more expensive and remain so today. Arcnet is simply much more expensive in terms of implementation. Second, Arcnet never made the transition from coaxial cable to twisted pair but relatively speaking, that's a minor issue.

Third, yes, it's deterministic. As in you can use every last bps worth of bandwidth without contention. Prior to full duplex Ethernet, this wasn't the case. However, speeds on Arcnet are LINEAR. It starts out slow and just degrades linearly to a crawl as the number of nodes increases. You can get more bandwidth only in exchange for a linear loss in bandwidth. With Ethernet it's a bit more of an exponential curve...everything works very fast with very low latency until you hit a "brick wall" effect, and that's even with contention (using hubs or a coaxial system instead of switches).

That's for bandwidth and latency. But the advantages of Ethernet/IP over RIO go far, far further than that.

You get lots of built-in troubleshooting support within an Ethernet network, and devices are isolated. Not so with RIO. It is common especially if you are fighting a bad connection problem to get reflections across the cabling where the bad player is not the device that is reporting connectivity issues. All you get is some flashing lights on the modules and a small map of presence/absence displays on the PLC. With Ethernet you get extensive diagnostic information even without managed switches.

In addition, you can use a ring structure and/or RSTP and often can get the recovery rates up so fast that physical cable failures are actually undetectable by the control system (without some sort of status indication), allowing for transparent failover in the event of a cable or even a switch loss. You can literally use pretty much any network topology that you can iimagine. That's impossible with RIO.

Furthermore, RIO uses a highly proprietary protocol that AB closely guards. You can't buy or take advantage of COTS (commercial off-the-shelf) technology which helps keep your implementation costs low. And it's not standards based so you can't buy parts from multiple vendors and make them work together seamlessly. It also doesn't have the more or less "self configuring" capability that you get with Ethernet/IP with automatically constructed configuration faceplates for IO, auto-recognition of IO cards, and the simplicity of consumer/producer based data sharing. Virtually every PC comes with an interface port built in. No more PCMK cards to fool with and all the compatibility and hardware issues that come along with that. And if you do lose a cable in the middle of the night, you can run down to Walmart and get cable for a repair if you really, really had to. You just can't do that with RIO.

In addition, despite having a much higher voltage (12 V vs. 1-2 volts), RIO is much less tolerant of noise issues. And Ethernet/IP has much higher resistance to grounding issues since the line transceivers use isolation transformers as an interface, completely eliminating almost all DC and low frequency interference.

Further, you get hot modifications. You can add or remove or change around the network structure even while the PLC is online and running. This also helps tremendously with troubleshooting as well as growth and modifications to the system.

Further, the address space is close to 2^32 addresses vs. 2^6, and the number of devices is effectively unlimited. With RIO you are stuck with 32 devices per network, and performance pretty much takes a dive once you get to about 10-15 nodes. It is possible to get to 32 nodes (I've gone as high as 31 nodes) but not without great difficulty. You can pretty much get as creative, flexible, or whatever you want with an address space that large.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users