controllogix

Forgive me if this question has been asked before. I want to get two cotrollogix to communicate with each other. There will be an input (start) from an HMI to plc 1 that will go to plc 2 and plc2 will send output to drive. Also would like to know how I can get speed ref from drive to plc2 to plc 1 back to hmi screen.

Without knowing whether your plc's are connected on a network it is difficult to offer any meaningful advice.

Yes they will be connected to each other through ethernet. Just need to know how to get inputs from plc 1 to plc 2 ....plc 2 will be responsible for outputs.
Also how do I get a 0 to 10v speed ref through plc1 to plc2? The connection are in place just unsure about the programming.

Easiest way is to use Message instructions to exchange data between the 2 plc's. You can exchange everything you've mentioned by this method but it does seem a bit of an odd set up. I'm sure you have good reasons for this though.

Yes odd set up

How can the 0 to 10v be sent or received through message? From what I under the message has to be triggered. Should I use an input to constantly keep it on?

Investigate 'Produced' and 'Consumed' variables. Once set up these are automatically transferred from the source (produced)to the target (Consumed) CPU.

There are at least three ways I can think of to do this sort of thing: MSG instruction, Produced/Consumed Tags, and Shared Inputs.

Each has its benefits and drawbacks.

From your description of the various data transfers, I would suggest Produced/Consumed Tags as the general-purpose solution.

You can read all about them in the Programming Manual for Logix 5000 Produced and Consumed Tags:

http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm011_-en-p.pdf

Two hints to get you going, that a lot of users overlook the first time:

1. You can't Produce/Consume a BOOL tag. User a DINT with a value of 0 or 1 if all you have is a single BOOL, or pack a bunch of BOOLs into bits of a DINT.

2. When the Producing controller is a 1756 ControlLogix, you have to first add the Producing controller's Ethernet to the I/O tree of the Consuming controller. When you do, select "None" as the connection type instead of "Rack Optimized"*.

* Unless you really do have an I/O rack with discrete I/O modules connected to your controller that also has a Producing controller in it. It doesn't sound like that's your situation.

Ken Roach said:

2. When the Producing controller is a 1756 ControlLogix, you have to first add the Producing controller's Ethernet to the I/O tree of the Consuming controller. When you do, select "None" as the connection type instead of "Rack Optimized"

Click to expand...

Sorry to hijack the thread for a moment, but I've not come across this tip before either - what purpose does this serve?

A "Rack Optimized" connection creates a cyclic I/O connection that can carry all the I/O data for all the discrete modules in the rack all at once. It's the most efficient way to run an I/O rack full of ordinary non-Diagnostic discrete I/O modules.

But if you are inserting the 1756-ENxT module and the chassis object into the I/O tree just to hold the 1756 CPU object, you don't need that cyclic I/O connection and it will just take up bandwidth on the network. So you can just select "None" as your connection type for the 1756-ENxT module.

You learn something new every day. Thanks Ken!

Ken Roach said:

A "Rack Optimized" connection creates a cyclic I/O connection that can carry all the I/O data for all the discrete modules in the rack all at once. It's the most efficient way to run an I/O rack full of ordinary non-Diagnostic discrete I/O modules.

But if you are inserting the 1756-ENxT module and the chassis object into the I/O tree just to hold the 1756 CPU object, you don't need that cyclic I/O connection and it will just take up bandwidth on the network. So you can just select "None" as your connection type for the 1756-ENxT module.

Click to expand...

In other words, only select "Rack Optimised" if...

1. You are using the remote comms module as a bridge for discrete i/o modules in the remote chassis. If there is no discrete i/o in the chassis, choose "None" as the Comm Format.

AND

2. You need to conserve the number of "connections" you are using, or need to conserve network bandwidth.

AND

3. Your discrete i/o modules can run at the same RPI, because the i/o data is amalgamated by the remote comms module. Having said that, it is quite in order to "rack-optimise" a remote chassis, and have a unique connection to individual discrete i/o modules, allowing them to "RPI" at a different rate if needed.

There will be a network, and connection usage overhead for using Rack Optimised as the Comm Format for a remote comms module when there is no discrete i/o in the remote chassis.

Analog modules do not take any part in Rack Optimisation, they will always utilise a direct connection, so if you only want to connect to analog modules in the remote chassis, also choose "None" Comm Format.

Question for Ken if he's following this thread.....

Any idea why it is not possible to specify producers using explicit pathing, like you can for messaging?

Thanks for the help guys.

I'm wondering if this is all unnecessary. Is the HMI on the same Ethernet network as the PLC's? If so, why not cut out the middle-man and have the HMI talk directly to PLC 2? You didn't say what kind of HMI you're using, but if it's a PanelView they're capable of talking to more than one PLC at a time.