Creating Produced and Consumed Tags Online

There are 3 "methods" you can use to exchange data between Logix5000 controllers :-

1. Produce/Consume
2. MSG Write
3. MSG Resd

I dislike MSG Write, because you lose traceability in the receiving controller - in other words, you have no idea where the data is coming from.

As an example of the relative merits of the remaining two methods, I once worked on a large project involving 7 or 8 ControlLogix controllers.

One of them was set up as a "data-concentrator", and harvested data from the other controllers for production data, batch reporting, alarm reporting etc. Most of the network was Ethernet, but there were a couple of controllers on ControlNet. The harvester was the only controller allowed on the corporate network, and was interrogated by SQL Servers and Historians.

In order to minimise network traffic, we set up a single DINT produced tag in each of the remote controllers, all consumed by the harvester. Each bit in each DINT was used as a trigger for the harvester to MSG Read the respective data block from the remote controller. We didn't even need to monitor for the bits coming on either, the consumed tag was used to fire an Event task, which was used to derive our MSG Read initiators.

So, we had a system that incorporated both produce/consume and messaging, tailored to our needs. Network traffic was minimal, by only Reading data when told it was valid, i.e. no cyclic messaging continually reading the same data repeatedly, just to pick up the changes every now and again.

I like analogies - and apologies to any "Brummies" who may read this, suppose you had a hammer and a screwdriver in your toolbox...

What could you use to put a screw in ?
What must you use to put a nail in ?

Nearly everyone in the UK is familiar with a "Birmingham Screwdriver" 🔨
 
At first I did not think I was going to get anything out of this post, but as the arguments progressed I actually gained a lot of knowledge after hearing each personal experience. I was not the one who initially designed this program so I was not able to plan ahead with extra P/C tags. My only option now is to use MSG to get the information I desire since stopping production to create P/C tags is not an option. Thank you all for your input. Hopefully this helps someone else who is in the same boat.
 
Welcome to the Forum!

Implementing a Produced/Consumed data transfer between two controllers requires the creation of the relevant Data Type tags and the addition of both 'connected' CPUs within the 'IO Tree' of the 'corresponding' one.

Unfortunately, this procedure will require Offline configuration and Download to both CPUs.

That is incorrect. You only need to add a "producer" to the IO Tree configuration of any "consumer".

"Producers" do not need "consumers" in their I/O configuration.
 
mjosephs said:
...My only option now is to use MSG to get the information I desire since stopping production to create P/C tags is not an option...Hopefully this helps someone else who is in the same boat.

I'm glad you are learning something here, but from the above it appears as though you might still be missing an important point that we were trying to make?

Its reads, to me, as though you are making a decision on which method to use based purely on whether you can stop production or not, rather than firstly considering if the tag data must be communicated implicitly, or not. You may have already weighed this up, but you haven't intimated as such, to us.

If you were to reply us, as you have now done, then I had hoped your reply would have focused more on the application dependencies and answered the preposed question of whether the data you "desire" is time-critical, or not. That is, do you think or know that explicitly messaging the data is sufficient to your needs? Other than the fact that the former requires stopping production, whereas the latter does not, do you understand the difference between implicitly and explicitly communicating the data?

You don't have to continue any further in explaining yourself, if you so wish. But doing so would, in my opinion, serve much better in assisting others in a similar situation who may stumble upon this thread.

Regards,
George
 
I'm glad you are learning something here, but from the above it appears as though you might still be missing an important point that we were trying to make?

Its reads, to me, as though you are making a decision on which method to use based purely on whether you can stop production or not, rather than firstly considering if the tag data must be communicated implicitly, or not. You may have already weighed this up, but you haven't intimated as such, to us.

If you were to reply us, as you have now done, then I had hoped your reply would have focused more on the application dependencies and answered the preposed question of whether the data you "desire" is time-critical, or not. That is, do you think or know that explicitly messaging the data is sufficient to your needs? Other than the fact that the former requires stopping production, whereas the latter does not, do you understand the difference between implicitly and explicitly communicating the data?

You don't have to continue any further in explaining yourself, if you so wish. But doing so would, in my opinion, serve much better in assisting others in a similar situation who may stumble upon this thread.

Regards,
George


Yes, I can see how my wording makes it sound like I do not understand the big picture. This data I desire is completely fine to be communicated explicitly since it not time-critical and rather just a process status for my own convenience. This data is not critical to the process itself and only needs to be updated when certain instances occur, so I would not want to use P/C tags anyway. Using P/C tags would just clutter the communications with redundant data transfer that is completely unneeded for my application.

Once again, thank you to everyone for giving input.
 
Thanks for the more "explicit" reply!

You have proven to be one such case in point where the application not only permits the use of explicit messaging, but where it actually suits the application better than the Produce/Consume model.

However, to keep things balanced and keep you and others informed of available options...

Don't forget that you can configure the P/C model to trigger an Event Task in the Consumer based on change of state of the tag data in the Producer.

Regards,
George
 
Last edited:
However, to keep things balanced and keep you and others informed of available options...

Don't forget that you can configure the P/C model to trigger an Event Task in the Consumer based on change of state of the tag data in the Producer.

Regards,
George

A caveat is needed there George.

A data-change of a produced tag, by itself, is not enough to convey the "state-change" to trigger an EVENT task in the consumer. You have to include an IOT instruction in the producer to convey the data-change event to consumers.

The system does not detect data-change in the produced tag, you have to do that for yourself, and IOT that tag.

I have attached 2 small programs, both V20....

Master.ACD has a Periodic task which just adds 1 to a produced tag, which is configured to send data-change event to consumers.

Slave.ACD has an Event task triggered by the data-change of the consumed tag. The event task just drives an output.

In Master.ACD I have AFI'd the IOT, and the consumer does not see the tag-change event, so the event task does not execute, the output does not toggle.

If I remove the AFI just before the IOT, the consumers see the data-change, and the Event task is triggered.
 
Yep, all good Dave. My "you can" was not intended as a "this is how". I hadn't time to explain it. Good on you.

Here is also a couple of technotes that brush the subject...

40733 - How does an Event Task based on a Consumed tag trigger?
Access Level: Everyone

48444 - RSLogix 5000: Send Data State Change Event To Consumers
Access Level: TechConnect

30620 - CompactLogix Event Task triggers
Access Level: TechConnect

My intention was just to point out that cyclic communications between a Producer and Consumer was not the only option available, and that for cases where the data need only do something when it changes, this type of configuration is available to the Produce/Consume model and that explicit messaging is not the only option in such cases. If an application dependency dictated that the data is time-critical, but is also required to be Event driven, then the Produce Consume model can achieve this.

Where the data is not time-critical, one could argue that the event triggered explicit messaging option is simpler to implement. But because the data is not time-critical, it is more a user preference as to which to use rather than which is best practice.

That is why I said it may be fine for the likes of DBLD99 to exclusively use explicit messaging, if their application data tends to never be time-critical.

As you said Dave - horses for courses.

G.
 
Yep, all good Dave. My "you can" was not intended as a "this is how". I hadn't time to explain it. Good on you.

I just didn't want people to think this stuff was easy, and skip out on proper training.....
 
Yet another poster slagging produced/consumed tags. Has the world gone crazy or have I?

It's you. :)

P/C brings nothing to the table that you can't do more easily and more quickly with messaging. Following a message instruction is trivial compared to ferreting out where a P/C tag came from.

If you limit yourself to just read MSGs, you will know where the data comes from.

With messaging you get a bit that says that things didn't go through as expected, and maybe you should look into it. I don't know of an equivalent in the P/C world.

I'm of the opinion that Rockwell created P/C to make people appreciate MSG instructions.
 
It's you. :)

P/C brings nothing to the table that you can't do more easily and more quickly with messaging. Following a message instruction is trivial compared to ferreting out where a P/C tag came from.

If you limit yourself to just read MSGs, you will know where the data comes from.

With messaging you get a bit that says that things didn't go through as expected, and maybe you should look into it. I don't know of an equivalent in the P/C world.

I'm of the opinion that Rockwell created P/C to make people appreciate MSG instructions.

Have to disagree with you...

If you create your Produced/Consumed tags as a user-defined type, you can include a member called ConnectionStatus, of data-type CONNECTION_STATUS.

That member has two bits, RunMode and ConnectionFaulted.

In combination, they tell you 100% whether the consumed data is valid, i.e. the program is actually running in the producer, and the producer is still producing data.

And it is much easier to see where the data is coming from, because the producer is quoted in the consumer tags
configuration. What is more, in the tag database, the "base tag" of a consumed tag is there for all to see. EDIT : Most pe3ople who use Messaging don't put any modules in the IO configuration, so to see where data is being Read from (or written to), you have to decipher the explicit message "path".
 
Last edited:
Have to disagree with you...

And you are most likely correct. It appears that the situation has gotten better.

My experience with P/C dates back to systems that were installed in '05. The designers (our Central Office group) didn't know much about conveyor systems, and less about how they interconnect in a Paint shop.

Soo, what they did was to tie seven PLCs together using P/C in the Phosphate-ELPO area, without diagnostics, no documentation, and different tag names in the various PLCs. Each PLC could, and would impact what was happening on its neighbor. This was in the v16 days of RSLogix IIRC. No idea if P/C supported all of those features that you mentioned back then. But our Central Office guys certainly weren't using these features if they were.

In another area of the plant we had the same thing, but thankfully the progression was linear in that there was the conveyor loading the unpainted job into the booth, the conveyor in the booth, the conveyor in the oven, and finally the conveyor in the storage/sortation lanes. If the storage area was full, we had to use the spares in the UDT to pass the information back to the first conveyor in the series through each of the previous conveyors so as to not allow any more carriers into the paint booth.

Yeah, I'll stick with messaging.
 
And you are most likely correct. It appears that the situation has gotten better.

My experience with P/C dates back to systems that were installed in '05. The designers (our Central Office group) didn't know much about conveyor systems, and less about how they interconnect in a Paint shop.

Soo, what they did was to tie seven PLCs together using P/C in the Phosphate-ELPO area, without diagnostics, no documentation, and different tag names in the various PLCs. Each PLC could, and would impact what was happening on its neighbor. This was in the v16 days of RSLogix IIRC. No idea if P/C supported all of those features that you mentioned back then. But our Central Office guys certainly weren't using these features if they were.

In another area of the plant we had the same thing, but thankfully the progression was linear in that there was the conveyor loading the unpainted job into the booth, the conveyor in the booth, the conveyor in the oven, and finally the conveyor in the storage/sortation lanes. If the storage area was full, we had to use the spares in the UDT to pass the information back to the first conveyor in the series through each of the previous conveyors so as to not allow any more carriers into the paint booth.

Yeah, I'll stick with messaging.

Clearly a poorly implemented system, but it would have been regardless of the methodology.

Now, as an experiment let's go back in time a couple decades. Your job is to implement PLC5's on a dipping line. You've got one on the e-coat system and one on the oven. You don't want a carrier to advance into the e-coat tank if there's a skid on the oven elevator. Would you physically wire an output from the oven PLC to an input on the e-coat PLC, or would you send a message over DH+?
If you followed industry standard practice at the time, you would have hardwired between the two. Both techniques had pros and cons, admittedly. But the difference was in how I/O is handled in the processor versus how messages are handled.
That is the difference here, produced and consumed tags are I/O! That doesn't mean they are always superior, but if I'm programming conveyor permissives between controllers they will always be p/c, not messages.
This thread has bordered on hostile at points, please be certain I'm making my argument with no disrespect.
 

Similar Topics

"RS logix 5000 Question" Having trouble Creating produced or Consumed tags online Having trouble Creating produced or Consumed tags online...Can...
Replies
10
Views
13,964
The idea here is to provide for a brief rapid influx of message codes while preventing sequentially repeating the same message. i.e. if two...
Replies
23
Views
501
Hello everyone, In a factory where we installed Citect 7.20 the computer began to show the first signs of end of life. They never considered...
Replies
0
Views
57
Hi everyone, I'm a last year student at the university in Ghent, and for my thesis i need to write a TwinCAT program that writes data to a .daq...
Replies
0
Views
119
When I go to create a new module in Studio 5000 I can't enter any information for the IP Address or change any other fields. Is there any fix to...
Replies
1
Views
238
Back
Top Bottom