Simplest way to change tag scope with Controllogix?

SilverLoop

Member
Join Date
Oct 2002
Posts
87
after a month of plc development, the customer has decided that they do not like all of my tags being defined within controller scope.

they also took acception to the fact that i did not make "extensive use" of udts.

i can understand their desire to keep programs in their facility somewhat consistent, but i have been submitting backups of my code every week and they have not mentioned it before now.

so, i am needing a way to change large numbers of tags that are defined with controller scope to respective program tags. what would be the best approach to take?

thank you.
 
SilverLoop said:
after a month of plc development, the customer has decided that they do not like all of my tags being defined within controller scope.

they also took acception to the fact that i did not make "extensive use" of udts.

i can understand their desire to keep programs in their facility somewhat consistent, but i have been submitting backups of my code every week and they have not mentioned it before now.

so, i am needing a way to change large numbers of tags that are defined with controller scope to respective program tags. what would be the best approach to take?

thank you.

Export/Import.
Export the tags to CSV.
Open it with Excel, save it with the name _Import after it. Save as a CSV.

Now you can create a back up of the file, delete the tags, import them using the CSV tool, and rock & roll.
 
Silverloop,

Since you are still in development, it's not that bad of a situation. If you have to do this online to a running program, it's a bit trickier.

Simply create the local tags you need with the same tag name.

Then delete the controller scoped tags.

The project should re-verify correctly with the local tags.

You can automate the creation of the local tags using the tag import/export feature. Edit the csv file by adding the appropriate program name in the "scope" column. (Blank in the scope column is controller scope) Importing the csv will create the program tags. You still have to delete the controller tags manually in RSLogix5000.

Good luck,
 
Last edited:
thank you both!

btw...would there be a performance issue with leaving all tags in controller scope?

it doesn't matter though, because the customer is insisting on the change even though it was never meantioned before now.
 
No.
The issue is properly using local variables and global variables.
When it comes to multiple program files and tasks, it is better to keep things local unless they need to be global.
 
SilverLoop said:
after a month of plc development, the customer has decided that they do not like all of my tags being defined within controller scope.

they also took acception to the fact that i did not make "extensive use" of udts.
If you're doing the job on a cost plus basis, OK. Otherwise, make sure they pay for the extra time.

If they have a programming style spec, they should have provided it with the request for quote.

Personally, I can't see anything wrong with having all tags scoped globally. If you have multiple programs and they need to interact, then deciding which tags can be local and which need to be global just takes extra time. PanelViews and RSView like to have tags scoped globally. I can't say for sure, but I think the additional level of addressing to get to a program-scoped tag probably impacts RSLinx comms.

As for UDT's - sure they're great, but they're not a panacea. Because its a new feature, I think some people tend to go overboard with their use. There is programming overhead associated with their use since the UDT elements need to be populated by your program. I mostly use them for making sense of the data to/from complex devices like drives operating on devicenet or profibus.

As for changing scope - when off-line it is possible to cut and paste tags from one scope to another within RSLogix.
 
Last edited:
I'd like to add my 2 cents here. First off, there is no problem for RSView or any other software seeing program scoped tags. And using UDTs is not only a good way to organise tags, but also speeds up development, and communication since RSLinx has "Optimize UDTs" options built in. I saw an improvement of over %20 when switching to UDTs. The other major reason for using UDTs is that each tag in a control logix takes up at least 4 bytes. Yes that's right, a boolean tag chews up 4 bytes of memory for the tag name. If you use UDTs the UDT name is the only memory wasted. So if you have 10 bools, in a UDT you just saved close to 40 bytes, per instance of the UDT.
 
Gerry said:
If you're doing the job on a cost plus basis, OK. Otherwise, make sure they pay for the extra time.

If they have a programming style spec, they should have provided it with the request for quote.

Personally, I can't see anything wrong with having all tags scoped globally. If you have multiple programs and they need to interact, then deciding which tags can be local and which need to be global just takes extra time. PanelViews and RSView like to have tags scoped globally. I can't say for sure, but I think the additional level of addressing to get to a program-scoped tag probably impacts RSLinx comms.

As for UDT's - sure they're great, but they're not a panacea. Because its a new feature, I think some people tend to go overboard with their use. There is programming overhead associated with their use since the UDT elements need to be populated by your program. I mostly use them for making sense of the data to/from complex devices like drives operating on devicenet or profibus.

As for changing scope - when off-line it is possible to cut and paste tags from one scope to another within RSLogix.

yes...they did not give me a spec that outlined to what extent they needed "controller scope tags minimized" or even to what extent udts were to be used. i did use the tags that were present for the powerflex 70s that were in the I/O configuration so that much is making use of a udt.

i was given this job with a very fast turn around without a functional specification of how the machine was to work. my main goal has been to develop that detailed theory of operation and then to translate that into my code. because of this, i started just developing whatever tags on the fly in controller scope that i needed as i wrote my control sequences that were to interact with other control sequences. it probably is not the most elegant, efficient, modern way in which to write the code, but that was not my goal.
 
The only issue I have with Program Scoped Tags vs. Controller Scoped Tags is that you can create duplicate tags. In the case of duplicate tags the Controller Tag will take presidence over the Program Tag. This may be a useful tool to some of the more experienced programmers and very confusing to the novices.
 
the controller scoped tag only takes presidense when you are not in the program that has the program scoped tag. If you create a program scoped tag in program "Valves" that tag will be the one you're referencing there, anywhere else, the controller scoped tag will be used. If done properly, the scope makes alot of sense.
 
Originally posted by bosko:
Yes that's right, a boolean tag chews up 4 bytes of memory for the tag name. If you use UDTs the UDT name is the only memory wasted. So if you have 10 bools, in a UDT you just saved close to 40 bytes, per instance of the UDT.

True. However, now the CPU needs to perform a masking operation to get at the bit you want referenced. So boolean operations become a two-step process. With the BOOL data type and take the memory hit the comparison can be performed immediately.

There is very little in the world that comes for free.

Keith
 
kamenges said:
True. However, now the CPU needs to perform a masking operation to get at the bit you want referenced. So boolean operations become a two-step process. With the BOOL data type and take the memory hit the comparison can be performed immediately.

There is very little in the world that comes for free.

Keith

I'm not really sure about this, although it makes sense, but I've never even gotten past 10-30ms scan times in my programs, but HAVE come close to using up all the memory. With today's PLCs it's speed is not an issue, but 64k of memory can run out in a big enough project. And then there's the issue of communication as I stated above. RSLinx is optimized to use UDTs.
 
kamenges said:
True. However, now the CPU needs to perform a masking operation to get at the bit you want referenced. So boolean operations become a two-step process. With the BOOL data type and take the memory hit the comparison can be performed immediately.

There is very little in the world that comes for free.

Keith

True, But remember that in the SLC500 and PLC5 that masking to access an individual bit happens for every single bit instruction - and it wasn't a performance issue there.

In UDTs I group the booleans together. However I don’t worry about it too much for controller and program scoped Booleans. The convenience of tag based programming is worth the memory hit. One thing I do however is create a boolean array for one shot storage bits and other generic uses.


In UDsIn
 
Originally posted by Alaric:True, But remember that in the SLC500 and PLC5 that masking to access an individual bit happens for every single bit instruction - and it wasn't a performance issue there.

Granted, but with the earlier platforms we didn't have a choice either. It was what it was and we needed to accept the performance regardless of what it turned out to be.

I typically only use UDTs if there is a compelling reason to do so. But then again, I'm easily compelled. As a general rule, though, I will use UDTs as a base data type for multiple instances of an object or if I need to interface to a formatted data block like a drive image from DeviceNet. Outside of that I just use carefully formatted tagnames.

The RSLinx optimization is a reasonable point, though. I think some of the benefit has to do with data request schemes, though. Does the HMI read all the tags on each cycle or only the tags on the active screen? If it's the former then using UDTs would have a big effect. If it is the latter then the benefit would only be seen if all the elements on a given screen were from the same or a small number of UDTs.

Keith
 
It's interesting when people talk about memory allocation in a ControlLogix. It doesn't seem to be as simple as we first think. I ran a couple quick tests using v15 and the estimated memory tool in RSLogix5000 and got some interesting results.

DINT base tag with a 40 char tagname (max) = 116 bytes (29 DINTs)
DINT base tag with a 1 char tagname = 80 bytes (20 DINTs)

OK, the 36 byte difference seems to match up to the tag name length. (minimum 1 DINT, maximum 10 DINTs for 40 chars) But what the heck are the other 19 DINTs for?

Alias with a 40 char tagname to a DINT tag = 88 bytes (22 DINTs)
Alias with a 1 char tagname to a DINT tag = 52 bytes (13 DINTs)

Same 36 byte difference due to tag name length but only 12 DINTs extra. Must be some method of identifying the base tag included in there, but it's not by tag name. (referencing a 1 char or 40 char tag uses the same amount of memory) It could be a hard address but that would only be one DINT.

Conclusions:
Declaring a tag has quite a bit of overhead associated with it.

The tagname itself is pretty straightforward. Each 4 chars costs you a DINT of memory.

Using shorter tagnames to save memory doesn't seem to be that important. A one char tag burns an extra 18 DINTs of memory over the one DINT to hold the value. If you want to conserve memory, create fewer tags instead.

Controller scope and program tags seem to take the same amount of memory.

UDTs and Arrays save a lot of memory by avoiding declaring individual tagnames. It looks like even more than you would think.
 

Similar Topics

We had one go down. we have a new one. Their emergency Number don't work. The Model is TLSA046AAH-330N01-007 A catalog says we need software TET...
Replies
2
Views
136
“The HMI files we cannot open—they were saved in V13—we do not have that—I cannot restore file –please have them save in V11 and send them back to...
Replies
4
Views
135
Hi guys! I'm working in Studio 5000 and have a bunch of armorstarts there (+- 40). I need to set up parameters for each of them, mostly just same...
Replies
0
Views
75
Hello brothers We are contacting you because an error like [display change is currently controlled remotely] occurred while using the equipment we...
Replies
2
Views
173
Hi all. I'm trying to set up communication between a 1756-L72 (EN2TR) and a 1756-L82 (CPU port) using produced / consumed tags. From the L72...
Replies
13
Views
343
Back
Top Bottom