Best practice: IO in local 1756 chassis?

[wildswing]

Hi,

Does Rockwell have an official stance on whether or not it's best practice to have IO modules in the local 1756 processor chassis?

I'm just trying to add some clarity to a discussion I had with someone who insists that the local 1756 chassis should be left for communication and high speed IO modules like counter cards. All other "standard" IO should be in remote chassis. He went so far as to say this is a recommendation from Rockwell and has read it on RA's web site somewhere.

Can anyone confirm or deny this? Can you post a link please? What do you guys do? Beyond what Rockwell says, what are your standard practices?

Once again, thanks in advance. Your feedback is always very much appreciated.

 

[rdrast]

Huh? Where a module is located doesn't make a lot of difference, since they all communicate over their set RPI. I suppose if you were using some old old 57.6 networking, local IO would be faster, but over EtherNet or ControlNet, the speed is determined by the RPI set for the module.

Do leave some slots for future communications, but most importantly, put IO where it is most convenient and cost effective.

 

[Paullys50]

I never seen/heard that recommendation "officially" from RA, but I do agree with the philosophy. Generally speaking, other remote IO form factors provide the same functionality, are usually cheaper and more flexible with design options.

 

[Bit_Bucket_07]

You'll never get faster access to an IO module's data than by placing it in the CPU chassis. That said, modern remote IO interfaces are fast enough to make this a moot point for most applications.

 

[kekrahulik]

The local chassis will have the fastest update rate (compared to IO elsewhere). However, the vast majority of inputs do not require the "fastest update". Also, there are certain cards that can ONLY be installed in the local chassis: Ethernet, Sercos, High Speed IO, etc.

For most of my systems, I know there are possibilities for future expansions/projects. With that in mind, I make sure that I DO NOT fill up my local rack with IO that could go elsewhere because it could hamper future projects.

So, I do not insist that IO must not go in the local rack, but I try to limit it and leave plenty of spare spaces.

 

[ASF]

If that's RA's thinking, why do you think they manufacture 17-slot chassis'? I mean, I'm sure someone out there might have a rack with all 17 slots taken up by CPU's and networking modules, but I doubt I'd run out of fingers to count them on.

Depending on the architecture of your control system, and your plant, and a whole host of other things, I can definitely see that there could be a very good reason for having all your I/O in remote locations, but I can't imagine RA ever suggesting that to be the definitive best practice way of doing it.

Is it possible that your colleague has slightly misremembered it, and the note was actually talking about how it's always best to keep "communication and high speed IO modules like counter cards" in the local chassis? That in and of itself definitely makes sense - and if you have so many of these cards, and such a small chassis that you have to choose between relocating these cards or "basic" I/O cards, then absolutely, you should put the high speed/comms cards in your local chassis, and your other basic I/O in remote ones. Perhaps your colleague has just remembered the first part of that idea, and then extended it to the second part incorrectly. To quote Monty Python's favourite logician: "Universal affirmatives can only be partially converted: all of Alma Cogan is dead, but only some of the class of dead people are Alma Cogan."

 

[nhatsen]

... the local 1756 chassis should be left for communication and high speed IO modules like counter cards. All other "standard" IO should be in remote chassis.

That recommendation only exists officially for redundant systems.

 

[Operaghost]

While it might be a practice for some, I do not believe RA recommends any particular standard for the Logix systems. Individual people might offer recommendations, but just because one person says so, doesn't make it an official stance for the company.

Now, the old PLC-5 and to an extent the SLC 500, that is a different story.

OG

 

[daba]

To put things into a different perspective...

A ControlLogix backplane is a communications network, its proper name is ControlBus, although universally accepted as "backplane"... Modules connected to the backplane "communicate" on that network, using CIP, at a mere 5 MB/s.

Adding a 100 MB/s Ethernet module to the chassis, and using it for remote I/O will not give you a faster data-rate than 5 MB/s, since the data ultimately has to travel across the 5 MB/s backplane.

And don't forget that any remote chassis backplane also runs at 5 MB/s.

Any data exchange between multiple chassis (plural) will be degraded by the asynchronous nature of the two ControlBus networks, and the bridging network (Ethernet or ControlNet), but the ultimate maximum rate that data is exchanged within a ControlLogix system will be determined by that 5 MB/s backplane communication, which will only ever be achieved within one chassis.

 

[wildswing]

Thanks for the replies fellas. All very good feedback. Much appreciated.

 

[Hundikoer]

To put things into a different perspective...

Adding a 100 MB/s Ethernet module to the chassis, and using it for remote I/O will not give you a faster data-rate than 5 MB/s, since the data ultimately has to travel across the 5 MB/s backplane.

Using 5580 CPUs with embedded Ethernet port should overcome this limitation?

 

[daba]

Using 5580 CPUs with embedded Ethernet port should overcome this limitation?

Not really.... what about the remote 1756 chassis ? The I/O modules can only communicate with the remote I/O communications adapter over ControlBus, so you are stuck at 5MB/s

 

[rupej]

I guess Ethernet transmitters could overcome that limit? Not that they need to, but...

 

[daba]

I guess Ethernet transmitters could overcome that limit? Not that they need to, but...

rupej, the thread was about a remote 1756 I/O chassis, not direct ethernet connection to I/O modules....

 

[thingstodo]

I mean, I'm sure someone out there might have a rack with all 17 slots taken up by CPU's and networking modules, but I doubt I'd run out of fingers to count them on.

Well, use 1 of those fingers for me. 5 CN2's, 5 L73's, 2 Prosoft serial cards, 5 ENBT/EN2Ts.

We are in year 3 of a decentralizing project - the Prosoft modules were retired, one process was split into 2 L73's, and another L73 was moved to the building where it's IO lives. We have 1 more L73, 2 EN2Ts, and 2 more CN2 that can move out of that rack in the next 2 years (maybe 5?).

Original design had produced/consumed of 100 DINTs per L73, updated every 20 ms. One L73 owned the Prosoft cards, which were the only interface to our Moore DCS. It was sorta ugly ...

The 5 other L73's that we have spread across different buildings have 2 CN2's, the L73, 2 EN2Ts and from 1 to 3 DNB. We normally use 13 slot racks, so we have just reserved the rest of that rack for intelligent cards. Our IO racks have similar numbers of spare IO and spare slots.

I have not seen a guideline or design suggestion from RA. I have heard similar design stories from 'older' consultants.

I have run into bandwidth issues trying to distribute DNBs into non-local racks. 10 - 15 VFDs, even if you are using an IO instance, take up a lot of bandwidth on your 5 mb cnet. But controlnet is old school (like me).