Two Processors in Control Logix Chassis ???


Thread Starter

J Evans

Basically, one processor would contain logic from a package plant manufacturer and the other logic developed by ourselves for other parts of the process.

Has anybody experience of doing this ?


Craig Spinharney


I am an instructor for Rockwell and in our courses for CLX we in fact use a 10 slot chassis with 2 processors. The class participants modify an existing application theat makes compressors.

The first controller tskes care of assembly issues (weld, press, stake), while the second controller controls quality/rejection issues.

In this scenario data is shared between the two controllers though in the real world, they wouldn't have to. The producer/consumer model used for communications over ControlNet as well as the chassis backplane greatly facillitates the sharing of data between two controllers.

Using two controllers in a single chassis is a VERY viable use and may even be required in some cases due to processor cycle scan time restrictions based on the application.


Craig Spinharney
Rockwell Automation

David Hoeflein

We are using two processors in the same rack as a Master and Slave controller. We needed to control some output durations to +- 10 msec. The routines had a scan time of about 4 msec and we did not want to dedicate 40% of the cpu time to this task. So we added a second processor and called it "the Slave". To send data to the processor you create some tags in the receiving cpu that are defined as "consumed" and you point them at "produced" tags in the sending processor. You specify a time interval for update. The system will allow you to do the same thing from the other controller using the same memory areas but this is not a good idea. The data will bounce back and fourth between the two locations often overwriting data you put into them with data received from the other processor. So, to prevent this, I use transmit and receive areas in each processor. I also use a naming convention where all produced tags start with "p" and all consumed tags start with "c". You cannot produce or consume a single integer. DINT's are ok. Custom types are ok as long as the definition matches in both controllers. The maximum size of a single produced/consumed memory area is 125 DINTs or data structures not to execeed the same amount of space. You can define many DINT arrays of 125 and produce them but each array is limited to 125 elements. This size limit is part of the backplane communications structure and effects everthing being transferred between modules. Messages are limited to this length too. I'm pretty sure that data transfers over the Ethernet have the same size limitation too. So, if you ask for a 1000 element array through RSLinx it's really doing multiple reads to get your data. There is a limit to the number of "connections". When you define a produced tag it defaults to allow 2 consumers. This doubles the number of connections so change it to 1 if you only have 1 consumer. The update intervals are non-synchronous with the scan so be careful of that. When any tag has trouble communicating due to a missing tag in the other controller or a change in a custom data structure that is not matched in the other unit the communications errors are unpredictable. You can check the module's status and get the correct error message to find the problem but, at the same time, the process symptoms may indicate that lots of tags are not working making the problem appear worse than it really is. The tags seem to take a few seconds to find each other on startup so I use a delay timer that prevents the controls from doing anything for 10 seconds after controller startup. 10 seconds is probably way longer than necessary but the process I'm controlling can wait 10 seconds before starting with no undesirable effect. On my system I'm transferring about 8K bytes at a 500 msec interval between the master and the slave. I use command registers to send the commands to the slave and response registers to get the status and responses from the slave. The data transfers happen even if the controllers are not running so don't forget to check the controller running status before you believe what it is sending to you to be valid. I also sequentially number my commands, never using zero, so I have some confidence that the responce I'm reading is in response to a sent command. The producer/consumer communications does use cpu time which is why I set the update to 500 msec. The producer/consumer communications runs at the highest priority and, when I left it at the default 5 msec my 10 msec routine was getting watchdog errors. Keep in mind that I'm transferring 8k of data though. If you want to send data at the lowest priority you can use message instructions but the time required is not deterministic like the producer/consumer method. The two processor arrangement works wonderful. We use the slave to store backup values of the control targets and shift tallys. This way we can stop the system load a new software revision and/or replace the master controller, and restart without losing data. The only time we lose data here is when we change, add or delete produced/consumed tags and have to change both programs at once. For this reason we quit using custom data types for master/slave communications and just made large arrays with lots of spare space. That's about all I can think of to say on this subject.

Josep M Lario

The use of more than one processor is a common procedure when you have 'heavy' programs, or for many other reasons such as concentrating PLC controllers (for instance instead of having "n" PLC-5 Controlnet all over the plant, in a CLX architecture you can have the "n" processors in the same a CLX chassis, thus they can talk eachother via ControlBus (ControLogix Bus): with that architecture you'll get more free bauds in your ControlNet since scheduled connection between PLC's are now managed via BUS. (even faster). I've not experimented problems with several processors into the same chassis, it works similar to a ControlNet network, providing deterministic interlocking between CLXprocessors, sharing I/O, and resources (ControlLogix chassis is a Gatway). Best Regards Josep