Adding a PLC to IO tree of another PLC

[cncsparky]

We have a new piece of equipment being installed soon that will need to pass a few handshaking bits between it and our main conveyor plc. I will be responsible for getting the new controller to work with our existing main plc.

The main plc is a L72 control logix, the new equipment will be a L3? compact logix. The L72 has two EN2T network cards, one for the plant network and one for local I/O and VFD's.

Usually, we would add the new plc to the plant network and message back and forth. To keep from having to deal with IT and the plant network, is it feasible to add the new plc to the IO tree of the conveyor plc's local network?

If so, how will I interact with the tags in the new controller? Do I still have to message, or produce/consume between the two controllers? Or will I have full access to the tags in the new controller from the main controller, much like a remote rack?

Thanks for any help!

 

[mellis]

We have a new piece of equipment being installed soon that will need to pass a few handshaking bits between it and our main conveyor plc. I will be responsible for getting the new controller to work with our existing main plc.

The main plc is a L72 control logix, the new equipment will be a L3? compact logix. The L72 has two EN2T network cards, one for the plant network and one for local I/O and VFD's.

Usually, we would add the new plc to the plant network and message back and forth. To keep from having to deal with IT and the plant network, is it feasible to add the new plc to the IO tree of the conveyor plc's local network?

If so, how will I interact with the tags in the new controller? Do I still have to message, or produce/consume between the two controllers? Or will I have full access to the tags in the new controller from the main controller, much like a remote rack?

Thanks for any help!

Avoiding dealing with IT is a pretty lousy design goal. I can understand your reluctance, but if that is the right way to go, deal with them.

There are situations where two processors on the same IO network make sense, realize that there are tradeoffs. You will not be able to work on the IO network without disrupting both processors. This is also true for produce/consume. But given that you have this situation, the answers...

You can still message between controllers.
You can produce/consume between controllers.
You do not have access to all the tags in the other controller, just what you produce/consume or message.

In summary, from the point of view of the controllers, it doesn't really matter if you talk over the plant network or the IO network, it works exactly the same. Placing another processor in the IO tree means one of two things: You are doing produce/consume. You are sharing IO (rare). If all you want is to message, you do not have to add the other controller to the IO tree, just connect them to the same network. That can be the plant network or the IO network.

 

[Pete.S.]

Let the new PLC do what it is suppose to do. To exchange a few handshaking bits - sounds like your best bet is to hardwire some I/O between the two PLCs.

I always go for hardwiring between systems for simple communication like one system telling the other that it is ready to receive a new product or whatever. Or if you need something like line speed you use analog I/O. And then for machine settings, alarm communication etc I'll use whatever bus available. But never between the PLCs directly, if you have a real plantwide DCS system that is.

 

[cncsparky]

We have a PC in the area with Studio5000, connected to the plant network, for troubleshooting several different pieces of equipment.

With the new controller on the local network of the conveyor plc, will I be able to go online with the new controller from the plant network? In other words, go through the EN2t of the L72, throught the backplane, to the local EN2T to the local network to get online?

 

[mellis]

In general, if you can browse to it in RSLinx, you can go on-line with it. So it should work. Up to you to decide if this is the right thing to do, but no technical reason why it won't work.