Contact and Coil | Nearly In Control



Tag Based Controllers

A PLC Tag is not a Description; nor is it a Variable Name

We’ve had tag based control systems for years now but some programmers just aren’t getting it.

The other day I was working on this machine that makes hand made quilts.  It’s quite an ingenious machine, actually.  The whole secret to this thing was this “Hand-O-Matic” stitcher unit that randomly inserts longer or shorter stitches to simulate making the quilt by hand.  That was the problem, though – the production manager said once in a while it just wouldn’t produce short or long stitches so the machine produces these perfectly stitched quilts that won’t even fetch a tenth of the price at the big box retailer.  The quality department kept rejecting them.

The drawings showed it was pretty simple.  The PLC has two outputs to the stitcher: one tells it to do a long stitch, the other tells it to do a short stitch.  Mike from the maintenance department had already determined that when the machine was acting up, those outputs weren’t working.

We’ve Got Tags, Let’s Use Them

I went online with the PLC and did a quick search for the output name shown in the drawings – nothing.  That’s odd.  Then I bring up the tag list and look for any tags with Stitcher in the name – nothing.  Finally I go to the hardware tag address for the outputs themselves and trace those back through the logic, and find they are being driven by some linear feedback shift registers.  Guess what the tag names for the outputs of the shift registers were…  “bits(3).5” and “bits(4).5”.  Well That’s Intuitive!

That’s an example of the first mistake I keep seeing: programmers who don’t even take advantage of tag based addresses.  This isn’t 1990 anymore; it’s time to move on.

Tags are not Variables

The second mistake is usually made by guys like me who programmed computers in school before they started programming PLCs.  The first time I saw tags I thought, “Great!  Variables!”  In languages like C, BASIC, and Pascal, the programmer has to use variable names that function as both a name and description.  You’ll frequently see variable names like “miFileLineLoopCount” – meaning, of course, that it’s a module scoped integer that counts up once every time you read another line from the file.  The only thing that keeps things sane is that they use lots of locally scoped variables that only have meaning within a single block of code, so you only have to worry about 20 or so variables at once.  In the PLC world, we’re largely stuck with tags scoped at the global or program level (though that’s changing).

So guys like me started creating PLC tags like “Inbound_Conveyor_Zone_1_Blocked”.  But the tag names are so long that when you try to view a decent sized rung of logic with 15 or so contacts, the programming software either wraps the rung in on itself or makes you scroll to the right 5 screenfuls.  It becomes unreadable.  Tags are not variables – let’s keep the descriptions separate.

Using Structured Tag Names

Every PLC program needs a structured tag naming convention.  When the machine was designed it was already broken down into zones, areas, stations, components – whatever.  Tag names should reflect this.  Have the tags make use of device IDs used in the drawings too.  It’s also important to make tag names short.  Consider this structured tag name: “S110_Deliv_PP”.  The description of that tag might be “Station 110, Delivery Conveyor, Part Present Latch [E1522PRX]”.  The beauty of ladder logic is that the description will be displayed over the contact or coil in the editor.  You don’t have to spell out “Station110…” in the tag name because anyone familiar with the system will recognize “S110…” means the same thing.

The advantage of this scheme is that the tag database can be displayed in alphabetical order, so all tags for station 110 will be grouped together, and all tags for the station 110 delivery conveyor will also be grouped together.  Do you need to add an identical delivery conveyor to station 120?  Just select all the “S110_Deliv_*” tags and copy and rename them to “S120_Deliv_*” and you know you’ve got them all.  Do you want to delete station 110?  Just select all the “S110_*” tags and delete them.  Before tag based systems this meant we had to hunt down all the addresses used for that conveyor and delete the descriptions for each one (or we could leave the descriptions in there just to confuse the next programmer who has to look at it).

So, let’s use tags with a purpose.  Come up with a structured tag naming convention and stick to it.

Oh… and if anyone’s interested in buying some authentic hand made quilts, let me know – I can get you a great deal!

No tags


  • Peter · August 13, 2010 at 7:49 am

    Hey, I know this article ist quite old and automation is not my custom domain.
    I have to deal with a large control system and I am wondering what exactly is the difference / correlation between a TAG and a PROCESS VARIABLE?

  • Author comment by Scott Whitlock · August 13, 2010 at 12:19 pm


    To me, a process variable is a physical value, like speed, temperature, etc., but a tag is a “handle” for a memory storage location in a PLC or PAC. So you use tags to store process variables, but you also use tags to refer to internal state or even partial computation results.

    Does that make any sense?

  • Peter · August 14, 2010 at 4:21 am

    Yes, it does make sense! So you can say a process variable is a domain value and the tag the location where its stored? The plc’s provide tags which are read by the control system which could be different plc’s or supervisory software. The latter could provide the values in the tags as process variables?
    Does this make sense to you
    Have you ever heard of “super tags”?

  • Author comment by Scott Whitlock · August 15, 2010 at 10:39 am


    I don’t see a need to make it that complicated. A Tag is interchangeable with the term “variable” in a traditional programming language. It’s any mutable value. The programmer defines what it represents, which could be a process variable.

    I agree that process variable = domain value.

  • @Scott · August 16, 2010 at 3:35 pm

    thx for your help!

  • ivirban · February 14, 2011 at 4:11 pm

    I faced the same situation with tags such as bit[3].5; this is automatically asign if you convert a PLC5/SLC500 program in RSLogix5000. Probably it was a rewritted program for a SLC and they don’t bother to change tag names.
    Actually I tested converting RSLogix500 to 5000 and there are few things to modify, I think it’s a document on AB site which tells you what you should take into account.

Leave a Reply


Theme Design by