produced and consumed tags

I have been asked to take 2 level transmitter readings from one controllogix to another. The 2 controllers are on the same controlnet. There are currently several digital produced and consumed tags going over controlnet. question one: is produced and consumed the way to go, or a message instruction (they are on ethernet also). Either way I have never set one up. Whatever I do, i need to do it online. Offline and a download is not really possible cause I can't shut down the system. Any guidance would be appreciated.

IMHO
I would set up a message routine in both processors and just message the data you want to move over, I personally like a message read on both sides. I also like to setup a heartbeat on both sides and make sure the processor i am reading from is not faulted, before i decide to use the data. The consumed and produced tag is difficult for me to troubleshoot or cross-refference.

Produced and consumed tags IMO are preferable to messages. However, you cannot create these types of tags online. They can only be created offline and then downloaded.

So short answer is that your only option will be messages which can be added/edited online.

OG

Neither....

Since both Controllers are on the same ControlNet, just share the Analog Input module.

It's simple to do - add the Analog Input module to both controller I/O configurations, and go for a "Full Share" - (i.e.don't choose "Listen Only").

Rules:

Input modules can be shared between processors - providing the configuration tag (the tag that is downloaded to the module to configure it), is the same in both (all) controllers.

The simplest and fastest way to achieve this is to copy/paste the module from the project that currently has it in the I/O tree, to the other project, download it, and away you will go....

Ask for more help if you need it.

PS Just seen your comment about not shutting down the "system". I have assumed the "newer" project can be downloaded. If it can't, I would make plans for a shutdown to achieve this, it really is the best way to make this work.

Now that is awesome! I didnt even know that was possible! But it cant be done online, can it?? And that was one of the criteria.

OOps...Just saw your Post Script, you covered it.

You can actually create new modules online, so you can add the relevant module(s) to the other project, but don't think you can paste a copy.

So you'd need to be careful to get the configuration the same manually.

You'll get a warning triangle on the module in the I/O configuration, and the I/O light flashing on the processor, until the C tag gets accepted by the module.

thanks for the help. suprisingly, the messages where very simple to set up. they are both working great. I may have to move more AI's soon so i will definatly look at either produced/consumed and sharing modules. There is an outage coming up so that will be the perfect time to take it down. thanks again! this forum is a lifesaver!!!

Just a word on that term "sharing".....

When you go to set this up, there is no sharing option anywhere. It is really just a term frequently used to describe the setup.

As Daba described, copying and pasting is the easiest way to do this. But as he later mentions it (pasting) cannot be done online.

Also I would warn you not to copy and paste if you intend to try the same thing with output modules. Copying and pasting the configuration of an input module results in two controllers both "owning" a module. While this is allowed on the input side, it is not allowed on the output side.

While not as easy as copy/paste, when setting up my controller to receive input/output data from I/O modules that belong to other controllers, I prefer to use the Listen Only option.

Listen Only for an input module means I will receive all the data the module has, but my controller will not store the configuration for that module. So my controller/program would not be able to change any setting on that module. If I were to "own" the module and then change the settings, there is a potential that I could break the communications between the module and the other controller(s).

Owning an output module means that controller and only that controller can control the individual outputs (as well as change configuration settings). Listening to an output module means I can read what the outputs are doing, but my controller would not be able to control an output. So I could write logic in my controller to respond to your output but I could not affect your output.

OG

Conversely, I would not go for the "Listen Only" option (talking about Input Modules here).

In a listen-only set-up, if the owner-controller loses comms with the module, then the module sees it has no connection, throws away its configuration, and stops producing data onto the backplane.

In the multi-owner set-up, either controller can be pulled, breaking the connection to the module, but the module still has at least one owner-controller, so continues to function.

I do take your point about changing the configuration, such as scaling, or alarm levels), however, in my experience, this is a rare(ish) occurrence. If such a scenario exists, then I would use the module in a Fixed Configuration, and perform any dynamic scaling or process alarm detection inside the Controller, thus negating the need for module reconfiguration.

In fact I believe module reconfiguration would not work in a multi-owner set-up. I think the module would reject the new Configuration tag if it were different to its stored configuration. The message that is used to do a Module Reconfiguration actually breaks the connection, then re-establishes it by downloading the C tag again.

In the single-owner set-up, breaking the connection would cause the module to "lose" its configuration data, thus allowing a new download, as opposed to the module retaining its configuration if another controller still has a valid connection .. One for me to try later.