Tag Scope

[G_DeMark 2]

Many of the PLC guys I work with just create all the TAGs as controller scope.  However, my background with VB.net (structured text like) has taught me to create variables with a more local scope when possible.  So what is the forum philosophy on  PLC Tag scope?  Do you think it is better to try and keep TAGs scoped within the programs they are used in.  Or for simplicity do you just stick them all in the controller scope?  What are your thoughts?  Thanks

[TimWilborne 108]

I like to have them all at the controller scope simply so that I can access them from any program.  Unless you are running duplicate programs with duplicate tags then I see no need for program scoped tags.  Plus you can't produce/consume program scoped tags.

I'd love to hear other's opinions on the usefulness of program scoped tags.

[Michael Lloyd 85]

Just now, TWControls said:

I like to have them all at the controller scope simply so that I can access them from any program.  Unless you are running duplicate programs with duplicate tags then I see no need for program scoped tags.  Plus you can't produce/consume program scoped tags.

I'd love to hear other's opinions on the usefulness of program scoped tags.

Ditto. I use local scope when I write AOI's and don't need the variable to be visible to an HMI or user but that's about it

[kaiser_will 65]

Controller scope & UDT (User Defined Tag).  That is the best method, in my opinion.  If you make a tag Local and want to use it in a different routine...well that is not going to work unless you copy the tag to another.  Oh, brother.

The real power, in my opinion, is with UDT definition.  

[AndrewG 13]

I try to keep them all Controller scope. This makes it much easier to look at all the tags you have on your system, and saves a lot of time troubleshooting in my opinion.

[Armadillo852 25]

I tend to keep them Controller scope if the cell is small and does not have anything that is a duplicate cell. But if I have, which we often do, have identical cells within a big cell, then I try and keep them Program Scope. Even for the HMI. This way I can create 1 program structure, and just copy/paste for the rest. It makes it easier for the tech if he doesn't have to search through a ton of tags in the controller scope. And it gives the tech another reference if one cell is working and the other isn't. The techs in the field for us anyways, think just the opposite of AndrewG, they get overwhelmed by having to look at so many tags at once if they are all in the controller. We have the same number of tags, but it they are broken up in smaller different places so it is so overwhelming.

AOI's for sure program scope.

UDT's can be all over the place as we have a lot of UDT's we use for comms.

Safety is always controller scope

 

[chantecler 15]

http://forums.mrplc.com/index.php?/topic/29045-controller-vs-program-scoped-tags/

Edited 20 Aug 2016 by chantecler

[PLCMentor.com 60]

While most of my tags will generally be controller scoped, I have to agree with Armadillo when it comes to duplicate program modules.  Using program scoped tags in the type of cells he refers to allows all of the tags in each cell to be named exactly the same due to their localized characteristics.  It organizes the data more effectively in those cases.  Many of the projects I do require that data be shared between different programs.  In this case it just doesn't make sense to localize your tags.  I really wish that folders were available at the controller level and then tag organization would not even be an issue.  Also, keep in mind that programming in a PLC and programming with other high level languages require a very different mindset.  In most programming compact and efficient are a big goal (unless you program for Microsoft ;).  In the PLC simpler is better.  We have to program for our audience, ie the end user. 

[Michael Lloyd 85]

Quote

 In most programming compact and efficient are a big goal (unless you program for Microsoft ;).  In the PLC simpler is better.  We have to program for our audience, ie the end user. 

I believe that it's possible to have both and serve the audience better.

I've learned quite a bit from other programmers over the years. Unfortunately the bulk or what I learned is "don't do that" in nature.

For me efficient means organized, extremely well documented, and compact tag structure. However, the audience of this board is extremely wide ranging. My methodology works pretty well for gas processing, compression, gas and oil pipeline SCADA, fired heaters, etc but would probably fall apart (though not completely) in a manufacturing or machine control environment. 

Compact tag structure- Specifically, I mean descriptive without being wordy, especially in a UDT. Example: Instead of MOV1.OpnLimitSwitch use MOV1.ZIO. ZIO is ISA Standard nomenclature for Limit Switch Open (not the only way to specify a limit switch but it's what I've used for a very long time). Instead of Emergency_Shutdown_Input for an Alias, use ESD or whatever the predominant nomenclature is for Emergency Shutdown. When I make a tag I have the HMI tags in mind. Typing takes time. If I have to type 12 extra characters for each MOV and there are 20 MOV's that's 240x2= 480 extra characters that have to be typed. Once in the PLC and once when configuring the HMI. That might seem trivial but in a large program it adds up.