Control Logix Naming Convention

benaiahhenry

Lifetime Supporting Member
Join Date
Sep 2011
Location
Corning, NY
Posts
267
Hi Everyone,

I am new to PLC programming and am working on my first project. I am using RSLogix 5000 and my question has to do with tags. Is there some standard for tag naming conventions? Or some system that you have found to work well? Or does RA have a standard they recommend?

I've enjoyed reading this forum over the last couple months and have already learned much from you all!

Thanks,

Benaiah
 
The standard for naming tags is really that there is no standard for naming tags. You can use absolutely anything you want.

I like to try to make them mean something. Just as with the other Allen-Bradley PLC's, the program documentation does not live in the PLC itself, but rather in some PC with the (original) file. However, the tag names DO live in the PLC.

If you've intentionally named your tag something that makes sense in your system and you've lost the documentation, you're program is still at least "semi-documented".
 
A good method is to use place them together.

Eg on a system with 2 valves...

Valve_1.opened
Valve_1.closed
Valve_1.fault etc

Valve_2.opened
Valve_2.closed
Valve_2.fault etc.

Doing this allows related tags to sit together and you only have to expand that tree if you need too.
 
Adding to my previous post.

To save time creating tags you can create a user defined data type.

This will allow you to create it once for say valve 1 and use it on valve 2.
 
as already pointed out, use what ever you want.
BUT !!
use a nameing convention that makes since, not only to you, but others as well.

over the years (20+) i have learned one main thing in regards to programming, a machine made of pure gold, with diamonds, pearls, and emeralds and cost billions isn't worth 10 cents if
maintenance cannot understand the program and debug the logic when the machine goes down. i have had 1 call at 5 pm solved over the phone in 20 minutes and 1 at 4 am also solved over the phone in 10 minutes. the plant was 3 hours away(hint, hint).

I am having to deal with that problem now. the OEM programmer wrote the tags and logic so only he can understand it and my bosses signed off on it. i have to pick up the mess.

also try to use your symbol tags to reflect the electrical print line number, helps us a lot.

regards,
james
 
as already pointed out, use what ever you want.
BUT !!
use a nameing convention that makes since, not only to you, but others as well.

over the years (20+) i have learned one main thing in regards to programming, a machine made of pure gold, with diamonds, pearls, and emeralds and cost billions isn't worth 10 cents if
maintenance cannot understand the program and debug the logic when the machine goes down. i have had 1 call at 5 pm solved over the phone in 20 minutes and 1 at 4 am also solved over the phone in 10 minutes. the plant was 3 hours away(hint, hint)

regards,
james

James

Are you trying to tell us that you include remote access with all your projects?

LOL. 🍻
 
Try to use tag names that will convey enough meaning should the documentation not be available - i.e. you don't have the offline project file. You can still go online and do an Upload from the controller, but you will not have rung or tag comments only the tag names.

Tag names can be up to 40 characters - so can be made so meaningful you find you don't need tag comments in a lot of cases. This speeds up your program development time a lot.

As mike.m pointed out - using User-Defined Types that you create yourself is also good practice, and saves a considerable amount of documentation. When you create your UDT, document the elements in the type definition. Then in Tools -> Options, have "pass-thru documentation" turned on. Also have "Append to Base Tag" turned on. Now you don't need to put any documentation on your tags at all, as each member of your tags will show the documentation from the UDT definition. Worth trying it to see what happens...
 
I use all capital letters when a tag is controller scope, all lower case when program scope.
I have seen a few guys use ai_fan_speed_sp =analog inout fan speed setpoint, ao_valve_command = analog output, i_part_in_position = input part present, o_xxx = output whatever , b_xxxx= binary whatever . I liked it when I first saw it but after working with this system. I am not a big fan of it.
 
If the OP would give some more hints as to what the system is - we could be MUCH more helpful.

Example - I was part of a conveyor system recontrol. The tags were consistently arranged by conveyor

Conveyor1_estopped_status
Conveyor1_running_status
Conveyor1_stopped_status
Conveyor1_Faulted_status
Conveyor1_run_pb
Conveyor1_run_hmicmd

Conveyor2_estopped_status
...


By including the controlled machine (if part of a larger system) this helps clarity. it also helps to label a tag if it is an input from a field device (Pushbutton), or an HMI screen (we used Wonferware), or labelling that a machine is in a certain state ("faulted"). We had lots of ".ind" (Indication) bits that were only used to drive colors on the HMI screen - helpful to know this when the operators claim that the screen turns the wrong color when starting up.


Just some examples- give us more OP !
-John
 
Thanks for all the replies! I appreciate it.

This current project is a Fill/Plug machine. Has a circular turntable full of canisters and rotates past a fill head and a plug head. The plug head has a chuck that lowers first and then the bit lowers down out of that. I'm not sure what else you might find helpful, so if there is anything let me know.

What I've been thinking about doing is basically what John did with [PartName]_[state | command]. For example:

ScrewBit_BoltSuccessFlag
Vacuum1_InitialVacuumReached
VacuumFillTube_OvertravelProx
VacuumFillTube_UpDown

I work for a small company and my boss (and myself) want a system that can remain fairly consistent across all our projects so that later we know what to look for when doing maintenance.

Thanks!
 
PLC Kid,

No, i didn't mean to include remote access.
I have never used remote access.

I have developed a relationship with maintenance where ever the oem i used to work did a job and learned their capabilities and what they would like to see. Sometimes its like my typical programming method with some revisions, other times its totally different. Point is, i try to make the program user friendly. Maintenance is happy, engineering is happy, management is happy, and you get repeat business versus a machine that's always down because maintenance cannot figure out the program, every one is angry because of the downtime and no more opportunities for repeat business.

i have reprogrammed several pieces of equipment and am in the middle of reprogramming a 5/05 now because the program was hard to understand, unable to troubleshoot because of multiple latch / unlatch instructions of the same bit(s), and the list can go on.

regards,
james
 
A while ago, I started making a naming convention (but don't know what happened to it). I think the best thing is to come up with a system and do your best to stick to it.

I used CamelCase http://en.wikipedia.org/wiki/CamelCase with the first few letters indicating what type of variable in lowercase. sp for Setpoints, eu for engineering units, or if it was just internal I would indicate the type of tag b,n,f,ai, do (bit,integer, float, analog input, digital output) Next would be the desctiption in Camel Case, and then "_" followed by any modifiers again in lower case.

So a tag might be euRamPos or hmiAlmReset_pb. On larger systems you might use ID tags if on the prints (spLic4010) I generally don't like to use underscore as it takes me more time to type.

The important thing about coming up with a consistant system, is you don't have to look up variables. Also if you have common components in a system, User Defined Types are great.
 
I've developed a preference for using descriptive tag names, however I usually include the electrical drawing tag as part of the RSLogix tagname as well, eg HS523_StartButton.

In North America both the ISA and NEC tag naming conventions are common. The ISA tag naming method is based on device/instrument function while the NEC tag is based on device description.

Here is a link to an ISA naming sheet that I posted on the forum a while back.

I also attached a spreadsheet of the NEC tag naming convention to this post.
 
Last edited:
My suggestions are:
1) Include the tag or device number shown on the drawings.
2) Make sure the name reflects what is happening when the input or output is actually on/energized (a "1")

The 2nd point, if done correctly should aid in troubleshooting. I can't tell you how much time I've wasted trying to figure out if a limit switch is wired normally open or closed or what's going to happen when I energize a solenoid (ie: will the lift raise or will it lower???).
 

Similar Topics

Greetings, Please see attached image. This is a tag array from a Zenon HMI applicaiton. I am trying to create this same Tag/UDT structure in a...
Replies
1
Views
1,497
I am wondering if someone can point me toward some programming standard documents for AB Control Logix. Ideally, they should not be too rigid or...
Replies
14
Views
840
We have a client who wants to upgrade from a PLC5 installation to Control Logix. They have four 5/80E processors with about 6 to 8 remote racks...
Replies
16
Views
774
I am trying to to the phone messaging from 1756 control logix PLC to one of the phone number for alarm alerts, What are the things I need to set...
Replies
6
Views
452
I need to get rid of them. I am attempting to convert an SLC program to ControlLogix using the saveas->.acd command. I have turned off the...
Replies
8
Views
458
Back
Top Bottom