Controllogix - Ethernet Overload?

Hello All,

We are trying to add a SCADA system to an existing Control network at a customer site for data gathering (Totalizer counts) per their request.

Existing System consists of;

1) ControlLogix Processor (w/ (13000 total tags)
2) 24 total ControlNet nodes with DI & analog I/O
3) 12 PV1000+ terminals throughout the plant on 1756-ENBT/A (connected using Industrial switches)

Custormer wants to add an RSView SE SCADA system with the following footprint.

Client Server Model with 1 HMI Server serving 2 R/W clients and 12 view only clients. HMI server will serve up all the existing (135) screens that are currently on PanelView Screens + additional 32 product Totalizer screens which will only be displayed on SCADA client machines. Logic will be added on to the existing PLC to incorporate product Totalizer's from 16 different lines.

Looking at the overall picture, I am beginning to think that Controllogix's Ethernet network is already crowded and wondering how adding this SCADA system will further affect the control system. Currently Panelview comms seems to be ok but screen changes takes about a second or 2 + anaother 2nd or so for the tags to update on the screen. But then again, I have seen this behavior from PanelView screens even if only one was connected to a system.

How do I know or at what point the CONTROLLER gets maxed out as a data server?

Currently it's serving up data to 12 PanelView screens thru RSlinx Enterprise. So as far as the controller is concerned, it's has 12 data servers running concurrently. Am I right on this assumption?

Then I will be adding another RSlinx Enterprise data server for the SCADA system. Wondering how the overall system will be affected when max number of 14 clients are connected and requesting data from the processor.

Can anyone point out any pitfalls and any improvement suggestions for the above system?

Thanks

But you're not adding 14 clients. You're only adding one server. The server consolidates the data and serves it out to the clients. That's how SE works...

Thanks OZEE,

But I am still worried about the load 12 Panelvew 1000's might be putting on the LOGIX CPU. Can it handle it? (it is currently working). But is it good practice? The way I look at it, there are 12 RSlinx Enterprise data servers reading/writing data to from this one CPU VIA the 1756-ENBT/A ethernet card. I guess what I am trying to find out is what is the recommended MAX data server connections per Logix CPU when it's actually acting as a data server for the rest of the system?

Thanks again.

Check out your ENBT card's usage & your SOTS allocated to the processor.
CLX's communicaitons are amazing, & I'd doubt you're currently pushing the envelope with this application.

skyfox said:

Thanks OZEE,

But I am still worried about the load 12 Panelvew 1000's might be putting on the LOGIX CPU. Can it handle it? (it is currently working). But is it good practice? The way I look at it, there are 12 RSlinx Enterprise data servers reading/writing data to from this one CPU VIA the 1756-ENBT/A ethernet card. I guess what I am trying to find out is what is the recommended MAX data server connections per Logix CPU when it's actually acting as a data server for the rest of the system?

Thanks again.

Click to expand...

I once heard that a PV is like a woman, very chatty. Imagine the background chatter if you had 12 women in one room taking about the same topic ( say the Oprah show the day before )

Ian

skyfox said:

Thanks OZEE,

But I am still worried about the load 12 Panelvew 1000's might be putting on the LOGIX CPU. Can it handle it? (it is currently working). But is it good practice? The way I look at it, there are 12 RSlinx Enterprise data servers reading/writing data to from this one CPU VIA the 1756-ENBT/A ethernet card. I guess what I am trying to find out is what is the recommended MAX data server connections per Logix CPU when it's actually acting as a data server for the rest of the system?

Thanks again.

Click to expand...

It's running now, so it must be able to handle it.

Is it good practice? I can't answer that, but I'm inclined to question it myself... What I can say is that if I had known in the beginning that I was going to have 26 HMI displays in the system -- 12 of them exactly the same, the other 14 exactly the same as the first 12 plus some other stuff -- I would have gone with SE in the first place. I might even be inclined to ditch the PanelViews now and replace them with SE clients.

The reason for that decision is very simple: maintenance. When you need to make a screen change, you make it in one place. You don't need to make the screen change 12 or 26 times.

Another thing you need to strongly consider in this new SE scheme: Use TWO servers - one for screens, one for data - and make them redundant for each other. And use yet another separate server as your domain server, unless your customer already has a domain server that you're going to tie into.

RSViewSE is an incredible HMI package. But it's not one that you just slop together as has been done in the past with PanelViews, PanelMates, RSView32, WonderWare, etc. For an SE installation to be truly successful, it needs to be designed intentionally from the beginning of the project, with careful attention to the details as outlined in the manuals. Play the game according to Rockwell Software's rules and the system will be a joy to work with. Try to cheat or ignore some of those rules and you'll hate the project all the way to the very end...

You should contact your solution architect in the local RA office and let him validate your application.

Technically in most of cases ENBT will not be a bottleneck, it will be a controller.
Hera are some numbers:

1.ENBT can safely handle about 700-800 class 3 packets (unscheduled comms like HMI, computers, messages).
900 is published number, but you don't want to hit the max and leave no room.
With any scheduled connections (produced/consumed, I/O) this number will go down very fast.

2.Controller L6x with system ovethead time slice set at 50% can handle maximum 250 packets/second. This number will represent 500 packets/second for enbt.
Why 500, why double? 1 controller packet = 1 incoming, 1 outgoing for ENBT, 250 x 2=500.

Each packet above is maximum 80 tags and only if this is optimized packet.

3.With typical SOTS set less than 50% and older controllers (L55) this number will go down dramatically.
With SOTS set higher than 40% continious task scan time goes up exponentially.
Assuming you don't have too much programming, scan is not critical and this is just a data concentrator, SOTS can be inctrased, and at this point you will hit ENBT bottleneck - see item 1.

4.Logical question: will EN2T do any better?
No, because you already put your controller to the max. You can add I/O or multiple controllers to the same EN2T, but you can't do it with one controller.

The bottom line - let RA analyze your application.

Can the PanelViews read their controller data from the SE server? I've never tried it, but have been told it's possible. That would reduce the number of devices communicating with the controller to one.

Contr_Conn said:

3.With typical SOTS set less than 50% and older controllers (L55) this number will go down dramatically.
With SOTS set higher than 40% continious task scan time goes up exponentially.

Click to expand...

Better yet, throw out the continuous task and replace it with a periodic one set at an appropriate scan rate, say 50ms. I've noticed significant increases in comms throughput doing this, because the controller is no longer constantly switching tasks. It runs its code, start to finish, then it goes idle and can burn through comms, then runs its code again, rinse & repeat.

The one time I actually measured the throughput, I got a 10-30% boost across the board with multiple clients involved, by switching all of my code from the continuous task into periodic tasks. This was back in the L55 days, so I don't know how much more efficient the L6X series is at task-switching, but every bit can help.

Face it, the L6X scans so fast that you'll typically be way ahead of your process and/or I/O. There's no need to be continually scanning your code every few milliseconds if you don't need to, and burdening the controller with constant task-switching between your code and communications.