ControlLogix: Dynamically Change Tag Names?

Colt Hero

Member
Join Date
Apr 2015
Location
USA - Southeast (but from Northeast)
Posts
109
Is it possible to dynamically change Tag Names (in real-time) on these PLCs? I'm guessing the answer is "NO", right? Just externally, then re-save, correct?

I've got multiple applications that are all pretty similar that are currently separate apps. They all differ here and there, but not substantially. I'd like to make them ONE application, fully configurable at start-up, but the "gotcha" is - the Tags to the Historian have to be unique. The Historians are running on separate Servers, but in one case, two of these apps write to the same Historian, so that eliminates the possibility of using (somewhat) "generic" tagnames.

So the workaround would be to have a routine that just reads and writes from/to the respective data sets based on the System selected at Startup, but it would be much cleaner if the tag names themselves could be modified at Start-Up after the System Selection is made.

Someone's probably gonna chime in and say, "You want a self-modifying program". Yeah - but only because these PLCs are so "name" driven, instead of memory-location driven. Or ... maybe it's because of the way their data exchange works (OPC). If this was a "conventionally-designed" system, it would just be data buffers with implied data positions. You could name the cells of the buffer anything you wanted in your local program.

Could the data be sent another way ... say ... in a block? The Historian is "PI", BTW.
 
Last edited:
Is it possible to dynamically change Tag Names (in real-time) on these PLCs?
Yes, with a couple caveats.

iirc you cannot change a tag that is (currently) being accessed externally.

You cannot edit AOIs online; this includes their tag names.

EDIT: Unless I initially misread your question and by 'dynamically change' you mean have the program itself modify the name, in which case afaik it is not possible.
 
Last edited:
Ok, I'm familiar with PI. I'm guessing you are using OPC DA Interface?

I'm not getting why you need to modify tag name since your OPC topic will be different.

Let's say you have PLC1 and PLC2, both 99% identical. Your PI "Instrument Tag" for the a temp probe TT101 that's coming from the same OPC server will be something like...

ServerA.ChannelA.PLC1.TT101

and

ServerA.ChannelB.PLC2.TT101

there's no worry about mistaken the two not to mention you can further define the tag with Asset Framework.
 
One thing I found was that you could not dynamically address arrays so have an array UDT
called SMC[0..12] and another variable called SMC_Addr and ref as SMC[SMC_Addr] in the code.

But you could not do the same with Alias they seem to be fixed at download. Like a #define Carrot 12 in C++
 
What I've done in "identical programs that have different tag names" is to make all the controller-scoped tags called "PLC_A_Thing1", "PLC_A_Thing2", etc. in PLC_A, and "PLC_B..." tags in PLC_B. This handles the historian uniqueness.

But I also have program-scoped tags called "Thing1", "Thing2", etc., as aliases to the controller scoped tags. Then when coding, ALWAYS use the local alias, not the controller tag. This way, if I make a change to a routine in PLC_A, I can blow away the routine in PLC_B and copy the entire routine into it, sight unseen, even online. The alias tags in the logic simply resolve to the different tag names. If they don't, it's probably because the base tag was part of the change.

Where there are differences in the code, these go into their own routine, so are never copied, at least not blindly.

I can even do spot checks on sameness. Copy the PLC_B program offline, search/replace the controller tags to make them PLC_A's, then us the compare tool to show the differences. The only place it should find are the places that are intentionally different and have their own routines.
 
Ok, I'm familiar with PI. I'm guessing you are using OPC DA Interface?

I'm not getting why you need to modify tag name since your OPC topic will be different.

Let's say you have PLC1 and PLC2, both 99% identical. Your PI "Instrument Tag" for the a temp probe TT101 that's coming from the same OPC server will be something like...

ServerA.ChannelA.PLC1.TT101

and

ServerA.ChannelB.PLC2.TT101

there's no worry about mistaken the two not to mention you can further define the tag with Asset Framework.

Oh ... Wait! You made me realize: I can make all of this a single program with one set of generic tagnames and load it to every application because the PI Historian can do the name translation for me! The PI Tag will have the unique name (with the identifying Equipment Tag), but the "Instrument Tag" field will hold the generic Tag Name in the PLC, differentiated by the PLC Topic Name (which specifies the unique PLC application).

Problem solved, right?

So to make every one of these very similar programs instead use a singular (the same) application, I don't use the actual Instrument and Device tagnames as my Tagnames in the application (as is currently done ... making the programs different from one another). I give generic names in the program, and then create the unique tags only in PI, translating each one via the "InstrumentTag" field, which specifies the Topic Name (which is the unique PLC).

I guess the one last question is: What if the Historian were to change from PI to some other product? I believe Rockwell uses PI as their Historian, correct (??) ... but what about other platforms like Emerson and Siemens? Do they have their own embedded Historians, and if so - can they do this kind of tag-mapping like PI does, or do the Tagnames have to be unique (and specific) in the PLC program?
 
Last edited:
One thing I found was that you could not dynamically address arrays so have an array UDT
called SMC[0..12] and another variable called SMC_Addr and ref as SMC[SMC_Addr] in the code.

But you could not do the same with Alias they seem to be fixed at download. Like a #define Carrot 12 in C++

Did you mis-type that? I think what you were saying is you CAN index an array with an integer variable tag, but NOT with an Alias ... correct?

So accessing array "SMC[SMC_Addr]" works as long as SMC_Addr is an Integer and NOT an Alias, right? Or would it still work as long as it's an Alias to an Integer tag?
 
What I've done in "identical programs that have different tag names" is to make all the controller-scoped tags called "PLC_A_Thing1", "PLC_A_Thing2", etc. in PLC_A, and "PLC_B..." tags in PLC_B. This handles the historian uniqueness.

But I also have program-scoped tags called "Thing1", "Thing2", etc., as aliases to the controller scoped tags. Then when coding, ALWAYS use the local alias, not the controller tag. This way, if I make a change to a routine in PLC_A, I can blow away the routine in PLC_B and copy the entire routine into it, sight unseen, even online. The alias tags in the logic simply resolve to the different tag names. If they don't, it's probably because the base tag was part of the change.

Where there are differences in the code, these go into their own routine, so are never copied, at least not blindly.

I can even do spot checks on sameness. Copy the PLC_B program offline, search/replace the controller tags to make them PLC_A's, then us the compare tool to show the differences. The only place it should find are the places that are intentionally different and have their own routines.

I get what you're describing here, but that's not quite what I was looking to do. See my Reply #6 above.

I have 7 Packaging Systems that may, or may not, use a few different optional equipments. Each program is currently written uniquely with the specifically-named tags in them. And some are coded for the optional equipments, and some aren't. But then, Operations have moved some of these optional equipments around from Packaging System to Packaging System, so these programs were subsequently modified (over time) to control these options. So now, the programs are similar, but not the same, and they each have the unique tagnames. And there are other issues, too, which cause aggravating "on-call" calls that I'd like to eliminate. It would just be better to have ONE application, generically-written, that is loaded to ALL OF THEM. Then, the Operators can choose what options are actually installed and run with it ... and Automation will have ONE application to maintain for all of them!
 
If you change to a different historian, your OPC tag will still be different even though your PLC programs are all identical.
 
Like Harryting, I'm not quite sure why there would be an issue with just having the identical program in each PLC. The OPC server will have different topics for each PLC. So the tags in the historian can be easily identified as MachineA.tag, MachineB.tag etc.

If you need some way to know if tag data is valid, have "Option Enabled" tags for each option, then in your reporting just cross reference that. May even be able to enable or disable data capture based on that tag value, I'm not sure if Pi supports that or not it's been 6 years since i last looked at anything Pi.
 

Similar Topics

I usually make a master program that I then use on different processes where the only difference is vessel sizes and setpoint ranges. I have the...
Replies
3
Views
1,971
Hi everyone i have a customer, who wants to show an alarm on the machine, if the I/O forces are enabled and set, on at ControlLogix L81E with...
Replies
3
Views
138
Does anyone know of a way to detect if someone is online with the controller in ControlLogix (from logic) I'm thinking that maybe there is a CIP...
Replies
7
Views
292
I've never paid attention to this, is this normal?
Replies
13
Views
418
Hi. I need suggestions. I want accumulate operating hours from a simple XIC condition, so I'm thinking a RTO with a 60000 or 3 600 000 preset, 1...
Replies
7
Views
225
Back
Top Bottom