modbus and allen bradley 1756-L63 processors

Hello Guys
i have recently been asked to look at a job,consisting of modbus and 5 allen bradley PLC's and around 30 racks

i have been told that the plc's are totally overloaded

controlnet is being used also,i wonder if you could give me some pointers on what to look for in regard to overloading/loading

my first thought is that too complicated code could be slowing down the processors,i am not a programmer but instrument guy,so i will be concentrating on the cabling etc

i would welcome your advice

That processor is a beast. Hard to believe it getting overloaded.
Where does the "modbus" in your title heading fit into the equation?
Are we talking Modbus ASCII or RTU? Serial or Ethernet?
When you say "overloaded" exactly what does that mean? What are the symptoms? Is it the controller that is bogged down, or just the network?

Please descirbe more about your system (hardware & topology) and your application.

You need to push on the guys who are saying the controllers are "overloaded" for exactly what they mean.

They might mean that the networks don't have a lot of available bandwidth and that messaging is going more slowly than they'd like.

They might mean that the controller programs are large or complex and that the programs are not scanning as fast as they'd like.

They might mean that the Modbus data doesn't update as fast as they'd like.

There's a nice utility called the Logix 5000 Task Monitor that can give you CPU Utilization numbers for the ControlNet modules and the CPUs. Those might help your discussion with the customer.

But don't go running down that road without a good idea of what the complaints from the user really are.

thanks Damian and ken

Modbus ethernet,i am waiting to receive more drawings but as it is my first time workign with allen bradley

"They might mean that the networks don't have a lot of available bandwidth and that messaging is going more slowly than they'd like."
if this is the case,what is the best solution?

"They might mean that the controller programs are large or complex and that the programs are not scanning as fast as they'd like."
this is what i am thinking as well but i am waiting for the information,how would i get around that problem? should it be this

"They might mean that the Modbus data doesn't update as fast as they'd like",what is the best route for improving updates

thanks guys

Without more details it will just be a lot of wild speculation.

The biggest puzzle is what the modbus is for? Do the racks have Prosoft cards? You already mention ControlNet, and I would expect that to be doing anything AB to AB. The Modbus would normally be meant for interfacing to something non-AB.

from what i gather

modbus is communicated through control logix processors

so controllogix to controlnet card on rack and then out on modbus card to other racks controlled by modbus

freesharo said:

from what i gather

modbus is communicated through control logix processors

so controllogix to controlnet card on rack and then out on modbus card to other racks controlled by modbus

Click to expand...

That doesn't make a whole lot of sense. AB doesn't have any racks that are controlled over modbus. If it is ControlNet you won't have Ethernet. If it is Ethernet then it will be EthernetIP not modbus.

I could see possibly third party "racks" like Beckhoff or the like where you would be doing ModbusTCP/IP.

Definitely have to wait until we have better information.

If the I/O racks are Allen-Bradley 1756-series (like the CPU chassis) then they're connected using ControlNet, not Modbus.

If they're devices from some third party then they might be Modbus. That would be a very unusual architecture.

Very frequently, ControlNet networks are configured for faster I/O updates than are actually necessary for the I/O devices.

To determine if the "network" is overloaded, you need to look at the loading of the 1756-CNB modules (the CPU Utilization) as well as the loading of the ControlNet network itself (using RSNetworx for ControlNet). Then you need to examine the actual necessary I/O update rates and compare them to what's been configured.

In the same way, sometimes ladder logic isn't written efficiently and calculations are performed every scan that could be performed every I/O update instead. That's going to require a strong understanding of the program and the intended control algorithms being implemented in it.

The first information I would get is:

1. A layout of the ControlNet networks for the overall system
2. The RSLogix 5000 programs for each controller
3. The exact part numbers of the Modbus modules.
4. The scantimes of each Routine in each RSLogix 5000 program.

thanks Ken and Damian

i think ken has it correct,i was sent some drawings but they are unreadable hence i am trying to make out what they are,i will let you know when i get to the site next week and get a copy of all drawings etc and the full story

thanks again

freesharo said:

i think ken has it correct,

Click to expand...

Ken always has it correct. We should just start calling him Yoda.

thanks to both of you

Answer future questions in Yoda syntax, I shall.

Change avatar, I will.

Ken Roach said:

Answer future questions in Yoda syntax, I shall.

Change avatar, I will.

Click to expand...

hmmmmmm yes the farce is strong in that one......

May the Yoda dog force be with you always.

The first information I would get is:

1. A layout of the ControlNet networks for the overall system
2. The RSLogix 5000 programs for each controller
3. The exact part numbers of the Modbus modules.
4. The scantimes of each Routine in each RSLogix 5000 program.

Click to expand...

I would also ask for copy of the programs in each controller, which let's see if the ladder logic is part of the problem.