Splitting a PLC between 2 CPUs


Thread Starter

Matt H

I have a situation where the PLC scan time is to high. I need to add an additional 1756-L63 to the same rack and split the program in half. Has anyone ever done this before and if so what are some of the things I nuances I should look for? Any suggestions would be appreciated.

Curt Wuollet

Depending on the program, this could vary from
cut and paste to impossible. It would be hard to
give any general advice.



We have done this for a few projects we executed with Control Logix. The issues to be addressed are:

a) Identify Tasks that cause the scan time to shoot up.

b) If such tasks are split in 2 CPUs, whats the information dependancy between the 2 CPUs.

The Tags that need to be exchanged are to be set up as Producer/Consumer Tags and exchanged. Is this acceptable?

c) Whether your existing program is modular enough to be split into 2 CPUs or do you need extensive rework?

d) Do you have Data to substantiate which Programs/Tasks are taking up the Scan Time?

We have experience in Control Logix multiCPU applications. You can check our website http://www.spsoftwareautomation.com.au

If your process has seperations this is not a bad job. Did it three times last year at the new Hyundai plant in AL. What makes it easy is if the PLC has more than one (and if they impact scan time) independant or semi-independant processess like work cells. What makes it hard is when there is no obvious break in the process so the split PLCs would be heavily dependant. This means lots of Produced/Consumed tags (I hope you have a clean control net).

Also the HMIs will take some time to change tag locations.

If you need help email me. [email protected]

Bradley Hite

Hello Matt,

About all I can say here is WOW. With the performance available with the L63 controller bringing it to an unacceptable level of performance is impressive.

It is definitely possible to divide the program up between two or more processors. That is one of the more unique capabilities of the Logix platform. However, I would recommend spending time evaluating what is causing the performance issues in the existing controller first. Things I would look into include:

1. Are you doing motion control?
2. How much math and how often is math being solved?
3. How much PID and how often?
4. How many periodic and event tasks? What is their priority and interval?
5. What is the system overhead percentage?

Feel free to contact me directly if you want.

Bradley G. Hite
Intertech, Inc.
mailto:bhite @ myplc. com
Teaching Practical Skills for a Technological World


I agree with the first person. My guess (and only that without more information) is that the original program is not well laid out that it used up the immense processing power of an L63. Again I have not seen the program so save your bullets for this messenger.

Possibly memory mapping, non use of arrays and lots of individual tags. The smallest memory size used is 32 bits long (one word).

Example : if you use individual bits and create 10 of them, you consume 10 32 bit words as each individual bit consumes 32 bits. An Array of 10 bits on the other hand uses one 32 bit word...... etc.

I have very, very large programs that will never touch the abilities of the memory and processor.

Also how you package words to pass to HMI etc, can consume extra memory if not laid out correctly.

Just my experience..........now on the other hand it could be a well laid out program and is just plain that big and I do not know what I am talking about. My experiences are usually the first.