Creating Produced and Consumed Tags Online

daba said:

... but you can add and delete 1756 I/O modules online, so why not P/C tags ?

Click to expand...

I have been asking myself (and RA) the same question for quite a while...I am aware it's been in 'the works' since the inception of Online I/O addition era...
Any day (FRN/Version) now...

I guess AutoMax's and myself's approach to Logix CPUs integration is 'too much work' for some or 'we'll worry when we get there' type engineering...Been around 24/7/365 operations with six figures 'losses' for one downtime hour my entire professional life...And these operations are the ones that specifically require the reliable, 'real-time' P/C type of data exchange between Logix CPUs...A properly implemented multi-controller system will indeed have 'built-in' provisions for I/O class communications between CPUs...There really is no substitute for it...You could get by explicitly transferring data, however, it still is a band-aid which needs to be addressed at the nearest 'idle' opportunity...Again, at least in my world that is...

I Explicitly disagree...

dmargineau said:

...Again, at least in my world that is...

Click to expand...

What do I always say?...

It should be application dependent.

Not "Hey, that's crazy?" or "Why would you do it like that?" or "I always do it this way, Yes Sir!".

daba said:

Definitely a case of "horses for courses".

Click to expand...

Here, here.

Not all applications are detrimentally affected by not using Implicit communications. It is not a default best practice to always use it, just because they are both Logix controllers. Explicit messaging between Logix controllers is permitted, and a perfectly acceptable method of communication, for certain applications.

Of course you would be foolish to use it where "six figures 'losses' for one downtime hour" are likely. Nobody here has said that they were doing that?
Also, nobody here has said that they were "substituting" required Implicit communications with Explicit messaging?

Ye are basing your opinions on what it is that you mostly to always have been required to do in these situations..."in your world". This may not always be the case for others. Why assume so?

If you want the ability to add or edit the Produce/Consume model on a running system then, by all means, continue to lobby Rockwell and bemoan that fact. But please do not call people amateur or unprofessional, just for choosing to use Explicit messaging on a Logix system.

Next you'll be telling us that we are unprofessional buffoons for still using Explicit based SLC and MicroLogix controllers, which are often doing similar tasks to Logix systems elsewhere?

G.

George,

If you take the time and follow the thread from its inception, you might might be able to extract the core of this disagreement; you were busy according to an earlier post.

The OP inquired about Online editing of P/C type data transfer.

Some posters on this thread (and a recent, similar one) suggested the P/C replacement with Explicit Messaging while stating this is an industry accepted approach.

The 'replace P/C with MSG' proponents seem to be quite unaware of the fact that this truly is an 'apples vs. oranges' issue and they are treating any CPU-to-CPU data exchange as 'fruit'.

If a functional system has implemented P/C data exchange there probably is a very important reason the developer decided to do so; the P/C data is most likely very critical in its nature; replacing or 'expanding' it with explicitly implemented data transfer is quite unprofessional and dangerous.

I hope we all are aware that Logix I/O (including P/C!) processing task has the highest priority while the explicit communications are the lowest one.

For the third time, and maybe this time it goes through, critical data needs to be P/C-ed; non-critical data could be MSG-ed.

How 'bout dem apples George?...

AutoMax said:

I've always assumed the inability to create p/c tags online was due to the impracticality of creating appropriate tags in two processors at the same time. It would be nice if there was a tag-level inhibit function that would get around that limitation.

Click to expand...

That's exactly the same scenario as adding an I/O module online without the module there... all you get is the "I/O Not Responding" minor error. It doesn't stop the processor.

AutoMax said:

One reason I prefer p/c tags (although as stated I do use messages) is that they are declared in both processors. How many times have you been at a customers site and done an upload, then had to figure out where data was coming from? P/c helps cut down on that. It certainly doesn't eliminate it, I'm sure everybody has tales of HMI's you can't upload from or OPC servers that no one in the plant knows about. "Now that you mention it, IT did remove an old XP machine the same day this line went down..."

Click to expand...

I have always recommended that the P/C tags in the multiple processors are 100% identical (which they have to be), but that they also have the same tag-name. I detest the "DataToPLC9.xxxx" and "DataFromPLC1.xxxx" scenario, you are always playing a guessing game.

For P/C tags, especially UDT tags, I've also always recommended creating them in one PLC only, then copying and pasting both into the other application. It guarantees like-for-like, and names them the same. Then you can reconfigure each as required to be Produced or Consumed.

dmargineau said:

For the third time, and maybe this time it goes through, critical data needs to be P/C-ed; non-critical data could be MSG-ed.

Click to expand...

"Critical" data might be production reports, only available as a batch ends, for example. No need, and overkill, to P/C that.

To keep analogies going, that's like harvesting all the apples off the trees, and only picking up a few, leaving the rest to rot away....

Perhaps it better to say "time-critical" data needs to be P/C-ed, nothing stands in its way, no ham-fisted programmer can harm it with inappropriate code changes, and it even continues if either processor is in program mode.

Not saying my way is the best by any means, but I map my p/c tags to tags of the same name, but a different prefix. "i" for a consumed, "q" for a produced, then an abbreviation for the data type, then the processor name. So one PLC might have "ixPLC2_SystemPermissive" as a tag, it's corresponding producer would have "qxPLC1_SystemPermissive." Maintenance personnel seem to catch on very quickly and appreciate it.
I'm sure any system can work well as long as it's consistently applied.

dmargineau said:

George,

If you take the time and follow the thread from its inception, you might be able to extract the core of this disagreement; you were busy according to an earlier post.

The OP inquired about Online editing of P/C type data transfer.

Some posters on this thread (and a recent, similar one) suggested the P/C replacement with Explicit Messaging while stating this is an industry accepted approach.

The 'replace P/C with MSG' proponents seem to be quite unaware of the fact that this truly is an 'apples vs. oranges' issue and they are treating any CPU-to-CPU data exchange as 'fruit'.

If a functional system has implemented P/C data exchange there probably is a very important reason the developer decided to do so; the P/C data is most likely very critical in its nature; replacing or 'expanding' it with explicitly implemented data transfer is quite unprofessional and dangerous.

I hope we all are aware that Logix I/O (including P/C!) processing task has the highest priority while the explicit communications are the lowest one.

For the third time, and maybe this time it goes through, critical data needs to be P/C-ed; non-critical data could be MSG-ed.

How 'bout dem apples George?...

Click to expand...

I wasn't going to reply to this thread again...but where in the OP did it say it needed to be time critical.... My post which was not claimed as an "Industry Standard" and was very accurate, besides calling P/C tags messaging, but indirectly you should have gotten my point about it being a better "Data-Transfer" if you can't shut the system down like the OP had indicated and was LOOKING FOR OTHER OPTIONS. If it it time critcal then yes you treat it as I/O and will have to shutdown the system to implement P/C. The OP was talking originally only about a few tags. Get off your high horse buddy and keep calm and P/C (MSG) on - its Friday.

Little Apples...

Oh, DBLD99 beat me to ya...leave some of him for me???

dmargineau said:

George,

If you take the time and follow the thread from its inception, you might might be able to extract the core of this disagreement; you were busy according to an earlier post...

Click to expand...

Firstly, if there is one thing Geospark likes to do, it's take his time and think things through. Secondly, I dare say I have ever not read a thread from the beginning that I have replied in. No, I can't think of one? In fact, I'll often, as I had done here, read it through several times while I gather those time taken thoughts.

Then I'll reply...

So, let's go back and read what you think I haven't, while highlighting what I find is key in pointing out that your (yere) arguments, while they have basis in certain cases, are not automatically the case here...

mjosephs said:

I have two L30 CompactLogix running on version 30 Studio 5000. They are both currently online and in production so they cannot be brought offline. The problem is that I need to produce a few tags on the one PLC and then consume them on the other. I realized that you cannot create these tags while online so I'm looking for other options. Is it possible to create these tags offline and then import them into the online program? Any suggestions or prior experiences are appreciated! Thanks.

Click to expand...

The two underlined comments are central to this...

Why do they "need" them?

That is, do they need to be of the Produce/Consume model?

That is, is it application dependent or critical that these particular tags are Implicitly communicated? Just because there is existing P/C tags does not mean the original design stipulated they must be. It is natural for a seasoned programmer to default use the P/C model where they can. But it does not automatically imply that it was essential.

If not critical, then what "other options" are possibly available?

That is, can Explicit messaging provide an acceptable solution?

It is still a possibility here that these new tags are not time-critical.

That is, we do not know either way, yet. So we should not assume either way or be a proponent of either method. If you insist on always using P/C, and won't budge on that, then that is your prerogative. But just because others may choose to use Explicit messaging, in cases where the data is not time-critical; you should not be calling them out as amateurs.

So, as I said (say), it should be application dependent whether you choose to use the P/C model or Explicit messaging to achieve your goal. All else said since, from one side or the other, is somewhat irrelevant until more context is given on the application dependencies. If our OP says that really these tags need to be P/C then knock yourself out if anyone suggests otherwise.

As is often the case, people assume that when I make a case against them, I am for the other side. I am, of course not. Where valid choices are available, I don't argue about the choices. Instead I try to focus on what should determine which choice one should make.

dmargineau said:

...Some posters on this thread (and a recent, similar one) suggested the P/C replacement with Explicit Messaging while stating this is an industry accepted approach.

The 'replace P/C with MSG' proponents seem to be quite unaware of the fact that this truly is an 'apples vs. oranges' issue and they are treating any CPU-to-CPU data exchange as 'fruit'...

Click to expand...

Again, I m not here to argue for or against. That belongs in that other thread, or for others here to continue with.

dmargineau said:

...If a functional system has implemented P/C data exchange there probably is a very important reason the developer decided to do so; the P/C data is most likely very critical in its nature; replacing or 'expanding' it with explicitly implemented data transfer is quite unprofessional and dangerous.

Click to expand...

You may be proven correct, and your experience does play a great part in weighing these situations up, as does mine. But "probably" and "most likely" are no certainties. That is my point. You are being somewhat assumptive.

dmargineau said:

...I hope we all are aware that Logix I/O (including P/C!) processing task has the highest priority while the explicit communications are the lowest one...

Click to expand...

That reads to me to be a little condescending? But I'll let it slide. I have lost count the amount of times I have explained that subject here, at length. You do not use Explicit communications where time-critical data is involved. There, I've said it again today. Will that make still your beating heart?

dmargineau said:

...For the third time, and maybe this time it goes through, critical data needs to be P/C-ed; non-critical data could be MSG-ed.

Click to expand...

And it certainly does not take me three "lessons" before I understand something, especially when I fully understood it before the first "lesson".

"goes through"?...

At the force you are making your point I will be amazed if it has been properly Risk Assessed? (Throws in cheeky dmargineau style to soften the blow).

You are shouting the odds here, somewhat, when, as I pointed out earlier, no one that I have seen thus far has said it is OK to use Explicit Messaging as a substitute where Produce Consume tags are required.

dmargineau said:

...How 'bout dem apples George?...

Click to expand...

I am rather partial to apples, actually. Keep them coming! (<<<)

G.

Geospark said:

I am rather partial to apples, actually. Keep them coming! (<<<)

Click to expand...

There you have it George...

...and that goes for the (apparently buddy) Friday pony rider too...

Read Post #1 again; and again; where is any reference to messaging?

Does P/C function akin to messaging as some 16 year veteran thought all along up until yesterday?

The question was about Produced/Consumed tags; there are NO OTHER OPTIONS for Produce/Consume handling as of today; period; the OP was inquiring of another way (short of Offline & Download) of creating P/C tags; I am pretty sure if he wanted to MSG data he would have not asked here about Produce/Consume; why are you presuming (George?) that he/she is not aware that he/she could programatically implement data exchange?

And what does he/she get for an answer?

OP:
I want to make apple pie but I can't get any apples when the place is running; do you guys know of any other options to get apples when the place is running?

Some Answer(s):
Well, you cannot get any apples unless idling the place, but why don't you make orange pie? Orange pie could be made at anytime by anyone and it still is fruit pie.

DBLD99 said:

Then use oranges. We have actually gone away from apples lately and gone back to oranges. Way easier to bake when you can't shut things down.

Click to expand...

Needless to say that, this day and age, there seem to be more and more available 'alternatives' to facts...

dmargineau said:

There you have it George...

...and that goes for the (apparently buddy) Friday pony rider too...

Read Post #1 again; and again; where is any reference to messaging?

Does P/C function akin to messaging as some 16 year veteran thought all along up until yesterday?

The question was about Produced/Consumed tags; there are NO OTHER OPTIONS for Produce/Consume handling as of today; period; the OP was inquiring of another way (short of Offline & Download) of creating P/C tags; I am pretty sure if he wanted to MSG data he would have not asked here about Produce/Consume; why are you presuming (George?) that he/she is not aware that he/she could programatically implement data exchange?

And what does he/she get for an answer?

OP:
I want to make apple pie but I can't get any apples when the place is running; do you guys know of any other options to get apples when the place is running?

Some Answer(s):
Well, you cannot get any apples unless idling the place, but why don't you make orange pie? Orange pie could be made at anytime by anyone and it still is fruit pie.


Needless to say that, this day and age, there seem to be more and more available 'alternatives' to facts...

Click to expand...

One could assume when the OP asked about "Other Options" with 3 total posts to his name - that he may or may not know ALL OF THE OTHER OPTIONS. Just because you think it was only pertaining to P/C, doesnt make you right. He hasnt responded to any of this and gave better specifics because YOU had to make this into a big cluster.

I won't respond to the 16 year vet thing - you are something else....Buddy.

DBLD99 said:

I have been doing this for 16 years(So not an amateur) and I use P/C a lot if you can take the line down.... My point was if it is a 24x7 operation. Messaging the old way is better.

Click to expand...

None taken...Just couldn't help it, buddy...

And the last statement in above quote?...MSGing is a different fruit...Especially when 'spelled' to a newcomer...I firmly believe the approach basics are more important than the apparent end result.

And to your intended point, 'old' (PLC/SLC) MSGing had indeed better CPU relative performance, however, the explicit data transfer is done a quite differently in Logix controllers; PLC messages are executed within each application cycle while the PAC (Logix) ones are triggered only when the CPU 'has time for chat'...

Anyway... and to your point again...TGIF...

If you need to add or modify the data transferred in a P/C tag while the process is running, it only takes a bit of preplanning. The way I address it is:

Create P/C tags for each data path required, make them all simple DINT arrays, leave plenty of extra room in each tag.

Map your tags of whatever type or structure in and out of the DINT array as needed. The P/C tag is just a block of data.

Now you can add and modify the data being passed through the P/C tags while the processors are running, since you are not changing the P/C tag's definition, only it's contents.

Now it is obvious that whatever size you make your P/C tags, you have the possibility of running out of room. However, with this approach you can see that problem coming and plan to increase a P/C tag size during the next available shutdown.

If you are absolutely committed to complex structure in your P/C tags you can still benefit from this approach. Leave a block of spare DINTS in your P/C tag, you can map new additions temporarily and modify the structure at your next opportunity.

I'm going to try to put a perspective on this "debate"

Some facts first..

1. A produced/consumed tag is limited to 500 bytes of data, so that's only a mix of 125 DINTs or REALs, or perhaps just one "recipe" UDT.

2. A MSG can transfer any number of bytes, you get the .DN bit when all the data has been successfully transferred.

3. A produced/consumed tag consumes a permanent "connection". A MSG doesn't, unless configured to "cache" the connection.

This is not an argument that anyone can win, there are situations where produced/consumed data transfers are beneficial, and there are situations where messaging data is beneficial.

The hard and fast rule is "don't put data traffic on the network unless you have to", which makes explicit messaging favourable in most circumstances, and leave produced/consumed implicit data transfers to when it really matters.

You simply cannot say which method is best, it will always depend on the nature of the data, and how frequently it needs to be transferred.

daba said:

...This is not an argument that anyone can win...

Click to expand...

daba,

This is what I'm trying to point out but you have probably summed it up far better than I have managed to so far. I am not in any argument here about which should be used or not. I'm more pointing out that to argue for one or the other, exclusively, is futile until you know the application specifics and dependencies.

I edited that in as you posted before I had the following just finished...

dmargineau said:

...Read Post #1 again; and again;...

Click to expand...

You are telling me to do something I have already stated as done. I can nearly quote the opening post for you at this stage, as can I recall their second and subsequently last post, which has not yet been mentioned. But that will come.

You are not opening my eyes to anything here. I know what the OP asked and the various ways in which it can be interpreted. I have already said that you could be right, but cannot be certain, yet. But you are ignoring my points that may prove to disarm you, or meet you half way and focusing on the argument that I'm not having with you...

dmargineau said:

...where is any reference to messaging?...

Click to expand...

There is no reference to messaging the same as there is no reference to Produce Consume being an absolute prerequisite. However, the latter can only be clarified by the OP, whereas, until the OP clarifies said latter, the former is still a valid "other option".

dmargineau said:

...Does P/C function akin to messaging as some 16 year veteran thought all along up until yesterday?...

Click to expand...

Are you seriously asking me that question? If you really want me to explain how "I" think they both work and what, if any, similarities they may have, then ask away. I'll be glad to keep you reading for the foreseeable.

I have at no point stated or suggested that Explicit messaging and Produce Consume are interchangeable. Please stop dragging me into the "proponents of using messaging over P/C" catagory. I've already explained that I do not take sides here. Choice is King. If you limit your choices in this business then I would say that that is somewhat unprofessional.

An honest question for you...

When would "you" use Explicit messaging between two or more Logix controllers?

I know what options are on the table here, and until the application dependencies are clarified (possibly might not happen now?), then those options will remain.

Moving on...

Knowing that the OP could not acheive their goal using Produce Consume while the controllers are operational, DBLD99 replied to a request for "other options". Other options could imply other options of implementing Produce Consume only, or it could imply other options alternative to Produce Consume. I can sensibly come to that possible conclusion. Can you, dmargineau? That's another honest question by the way.

Here is that reply providing an "other option"...

DBLD99 said:

Depending on Version of 5000 - You can create a UDT with everything you need and a SPARE DINT[xx] and REAL[xx] online. Reason for the spares is once you create it and utilize it with a tag you won't be able to change it online anymore.

Then use regular messaging. We have actually gone away from P/C tags lately and gone back to messaging. Way easier to maintain when you can't shut things down.

Click to expand...

AutoMax said:

Yet another poster slagging produced/consumed tags...

Click to expand...

I don't see any signs of "slagging" the Produce Consume model here? They have, for their own reasons decided to primarily use Explicit messaging over Produce Consume. Whether I would endorse this biased practice is another matter. It can appear to be a somewhat poor practice on the face of it. It is certainly not easier to implement, the most reliable, or the intended goto method for the Logix platform. But again, I don't know the applications that it's being implemented in, so it might suit their needs.

I don't advise anyone, uninformatively, to use one method or the other. Give me the application's specification and then it's a different matter. I could then advise ad nauseam. Then I would be as passionate in my replies as you are, if I felt that someone was being led astray.

dmargineau said:

...why are you presuming (George?) that he/she is not aware that he/she could programatically implement data exchange?

Click to expand...

I don't like to blindly assume or presume to know anyone's experience on a given topic. I prefer to ask or summise as best I can.

Our OP's reply to the above "other option"...

mjosephs said:

How would I go about using a UDT to let the one PLC read specific tags from the other? I'm currently using Version 30 of Studio 5000

Click to expand...

With respect, the above has "I'm not too sure about all this" written all over it. It suggests a level of uncertainty about UDT's and how one would use messaging with such UDT's. If our OP was au fait with messaging, as you suggest they most likely are, and I am incorrectly assuming they are not, then their last post would not imply as such, to me.

However, you have made a valid point here...

dmargineau said:

...I firmly believe the approach basics are more important than the apparent end result...

Click to expand...

This is also my belief. We should always endeavour to explain the basics, or fundamentals to an OP, especially when they may appear somewhat "Green" on a subject. The fundamentals of communicating tag data between two or more Logix controllers should include both methods. If Implicit is a requirement, then you can point out the pitfalls of using messaging over Produce Consume. But why say you that when you seem to think they are not so "Green"...

dmargineau said:

...The question was about Produced/Consumed tags; there are NO OTHER OPTIONS for Produce/Consume handling as of today; period; the OP was inquiring of another way (short of Offline & Download) of creating P/C tags; I am pretty sure if he wanted to MSG data he would have not asked here about Produce/Consume; why are you presuming (George?) that he/she is not aware that he/she could programatically implement data exchange?

Click to expand...

That doesn't sound like you think they need to learn anything other than what you have provided in Post #2, or since?

If you happened to be incorrectly assuming that they only want a Produce Consume type option here, and nothing else will do, and the OP said no, messaging will fit the bill nicely, will you then yield?

Or will you then move to them and start calling them amateur and unprofessional for not using Produce Consume, regardless of what the application will allow?

This is not an I'm right your wrong scenario. I don't care which way it slides as long as the OP has all the possible options made available to them. If the application specifications narrow, then the options will narrow.

But I don't choose, nor recommend others to choose, to close off such possibly viable options, until that conclusion can informatively be reached.

Please don't continue "SHOUTING" at us/me about when/where/why the Produce Consume model should always be used first and how the use of Explicit messaging is a "band aid" solution.

Members are already starting to point out cases here for you, for and against both methods. As did Firejo in that other thread you linked earlier. Which I also fully read.

One size does certainly not fit all here.

G.