Tags

I asked a similar question in the PanelBuilder 32 thread but thought maybe it should be a thread of its own.

I have programmed/setup several Operator Interfaces like Panelview, Magelis etc and they require the use of "Tags". Can anyone offer an explanation of what "tags" are? Or know of a tutorial pertaining to this subject?

Another question, Is there a ratio between I/O count and "tags"? A rule of thumb per se?

I know, silly questions, even though I have worked with "tags" I dont think I fully understood exactly what they are, at least not good enough to offer a description if asked for one.

Thank you for any replies.

Tags - God's Gift to Screen Writers!

As I understand them, "tags" are nothing more than variable names assigned to given IO points.

For instance, say you want a light tied to "O:12/14" to indicate "Running", and you are assigning the lamp on the screen. When you get to the "PLC Reference" box, it's a whole lot easier to write "Running" than "O:12/15".

(Ah, I just caught my own typo. I'll leave it there to illustrate the point.)

I use Exor panels, and until the latest revision of their Designer software, Exor did not have tags. My last big project included 4 PAGES of hand-written I/O points, integers and status bits, with definitions beside them, so I would know what address to use for what screen indication. I almost stopped using them altogether because of this.

Tags are wonderful, and if you ever consider the alternative, grab a copy opf Exor Designer, version 5 or earlier, and try to program a simple screen with three or four indicators. You will swiftly become a believer.

TM

Once Upon a Time...

... tags used to be stamped pieces of metal, with some kind of identifying number on them, like in dog tags. These would be attached, usually by the device manufacturer, to identify a particular device (valve, motor, photeye). They still are these things to this day.

You can imagine the choas that goes into building a new plant. You'd get a shipment of 100 valves, of all different sizes and configurations. But the valve would have a tag on it labelling it as XV-123, and on the P&ID drawing there would be an object "XV-123" which would show where that valve got installed.

Those tagnames became the "name" of the object. When HMI's came along, the engineers would draw the HMI screens based on the P&ID, and because P&ID's sometimes don't quite reflect the physical configuration (especially in crowded areas), the engineer would put the tagname near the drawn object to help identify it.

In those early days, you would often still reference the HMI's internal memory addresses, rather than using anything sensible, like English. The old Panelveiw 1200's worked that way, as did Nematron.

But nothing lasts forever. HMIs had more memory. PCs, with lots of memory became HMIs (sometimes called SCADA). Some folks came up with the clever idea of creating a database to interface between the communications driver (that which talks to the PLC) and the screen animation. That database is a simple flat file, with fields like "Description" "PLC address" "Which PLC (for projects that might read N7:0 from several PLCs on a network) has that address" (shortened to 'Node name'), and so on.

But what to call the key reference field? When you animate valve XV-123, which database field should you reference that will relate to this specific tag? English being what it is (e.g., fluid), that field is called the TAG. And English being what it is, the entire record (i.e., a single line in the database, consisting of the fields "Tag", "Description" "Node" "PLC Address", etc) for that particular tag is sometimes also called the Tag. The database will be referred to as the "Tagname database"

Of course, as things continue to evolve, you get "Tags" that don't have anything to do with real devices with real tags. You have "Internal Tags" or "Memory Tags", in which the HMI keeps track of the value, rather than reporting back to the PLC.

Most SCADA manufacturers price their product based on the size of the database. Why? Because of the old days when memory was expensive and it took effort to write programs that could handle several hundred tags efficiently. And as a marketing strategy. If a SCADA vendor underprices their "300 Tag" licence, they can get people hooked on their product, and can recoup their initial losses with sales of "Unlimited Tag" licences once they have market share.

But, especially nowadays, there is no difference in the software between these licenses. If you hit your tag limit, just change your licence (hardware dongle or software key) and you're good to go.

Is that more than you ever wanted to know?

Is that more than you ever wanted to know?

Click to expand...

I am greedy I guess, I have more questions. That was a great explanation though, I will probably borrow it.

Another question, Is there a ratio between I/O count and "tags"? A rule of thumb per se?

Click to expand...

Any general rule thats followed?

I am not sure how to phrase the next question properly. I am familiar with some of this to a point. I will try this as an example, I have PB32 (3.70.00 Build 136) and I create a New Project with a PV550, how do I know how many tags there can be, is it unlimited, is this one of the "it depends" situation? Now that I am asking it I think this is probably a "it depends" situation in most cases.

As far as I know, and I'm taking Citect as an example, there is no relation whatsoever between the number of I/O points and the number of tags. A tag can be a single I/O point, a byte, a word or even a double word.

If you are using a 16 bit IN and 16 bit OUT PLC in combination with Citect, and you're only using the in- and outputs as tags, this means you can get anything between 2 and 32 tags. If you first copy these bits to a continuous range of internal bits, you might even find 1 tag suffices! I once tried to take the bits from the PLC in pieces of 32 bits as being 1 tag each and subsequently filtered out every single bit as an internal tag (which BTW didn't count for the dongle with Citect), and guess what! Even that worked fine. The system only needed more time to calculate everything.

Kind regards,

Jean Pierre Vandecandelaere
Trainer PLC - SCADA
VDAB Bruges
Belgium

A "tag" in PB32 is simply a name that the application developer (you) gives to an object (such as a pushbutton) in a PanelView application.

When you create a tag in the Tag Editor or the Tag Form (in PB32), you link the given tag name to a specific address in your controller. You also set a Data Type for this tag which must match the data type of the address in the controller.

As far as a relationship between tag count and PLC I/O count:
You only need enough tags for the data that is being passed to/from the PanelView. You only need to be sure that the tag addresses that you set up in the PV actually exist in the controller.
Other than that, there is no real relationship between the tag count and PLC I/O count - there may be I/O points or addresses in the PLC that the PanelView does not care about.

I am not sure how to phrase the next question properly. I am familiar with some of this to a point. I will try this as an example, I have PB32 (3.70.00 Build 136) and I create a New Project with a PV550, how do I know how many tags there can be, is it unlimited, is this one of the "it depends" situation? Now that I am asking it I think this is probably a "it depends" situation in most cases.

Click to expand...

It depends.
I have not found anything in A-B documentation about a limit on the number of tags. However, a tag takes memory, and along with the memory taken by your screens, you need to stay within your memory capacity.
How many tags is that? I have no idea. But I have created hundreds of ControlNet tags in a PV1000 application with no problems.

I hope this helps to clear things up for you.

-Phil

I was writing this in the original post while you were creating this thread!

"Tags are a historical artifact, like your appendix. Unfortunately, they are gaining in popularity.

Most SCADA systems trace their roots to DCS in the process industries, where every field device had a tag name and tag number. These tag numbers were derived from adn shown on the Process and Instrumentation Drawings. When SCADA came in, because the process and DCS engineers were used to thinking in terms of tags, they included tag names in the set-up portion of the I/O being read and displayed. The scaling, addressing, register location, data type, etc. were all part of the tag data base.

When PLC O/I devices started showing up they were generally register based, having evolved from timer access modules and hand held programmers and such. You just plug in the data register and PLC address and you are done.

SCADA software for some reason has influenced O/I software rather than the other way around. I suppose the more complex O/I software stole programmers from the SCADA folks. At any rate, more and more O/I seems to be tag based. I personally think it takes longer to set up and maintain a tag based configuration than one with straight register addresses, but there may some hidden advantage to tags."

I also use EXOR O/I and I like it better without the tags. I always have a cross reference list for my I/O and registers anyway, and I find it just as easy to look up the register as it is to remember Pump 1 Running (or was that P-1 ON, or P1 RUN STAT) and so on. Maybe my brain is getting calcified.

As far as the relationship between I/O and tag count, it depends on the software. Some SCADA stuff (Lookout for example) only count the physical I/O and registers read from the comm link in the tag base. Others (like Wonderware) count every data point put on the screen as a seperate tag. Most operator interfaces don't limit tags per se, just toatal memory use but that also varies with supplier.

Yes, it's Standard Answer #0 - IT DEPENDS.

There are actually two questions you are asking simultaneously, which might be what's tripping you up:

1) How many tags for a given number of I/O will I need?
2) How many tags can be created in a PanelVeiw 550 (i.e., is this box enough, or do I need something bigger/else)?

It depends not just on what you are trying to do (e.g., display information), but also on how you are trying to do it.

For example, take a simple valve XV-123, with open and closed limit switches XVC-123 and XVO-123.

One way to animate this is to draw the valve and animate it with a tag that reads the output to XV-123. Next to it have a multistate object with the text "CLOSED" (with colors black on black or red on black) whose tag monitors the input for XVC-123, and another one for "OPEN" green-on-black tied to XVO-123. Three animations, three tags.

Alternatively, in the PLC, you can map the closed limit switch to bit 0 of a single word, XVO-123 to bit 1, and output XV-123 to bit 2. No you have a single word with the following truth table:

Value | Description
=== ==============
000 CLOSING (Valve not energized, but not yet closed)
001 CLOSED
010 CLOSING (Just, or perhaps stuck open)
011 TROUBLE (one of the limit switches, probably XVO-123, is stuck)
100 OPENING (valve energized, but not yet open)
101 OPENING (just, or perhaps stuck closed)
110 OPENED
111 TROUBLE (a limit swtich, probably XVO-123 is stuck)

You can create a single tag to read this one word (or array of 3 bits), and create/animate a single multistate object with a graphic and text.

So which one takes less Panelview memory? I don't know, and I'm not sure anyone else does either!!!!

Huh?

Its a trade-of. Two less tags, and two fewer objects, but you've gone from 2 times 2 states (with assoociated text in the text database) to 8 states of text. I would guess the later is more memory friendly, but I would be guessing. There's just no way that I know of to know, until it's done.

Multiply this by lots of different screen objects, different screens, different goals, and the whole thing is a crapshoot. Even Panelbuilder doesn't know if the application will fit in the terminal until it tries to download to it (at least in v 3.71 and lower. I don't have 3.80 yet). A project will verify just fine, you go to downlaod it, and THEN you are told that there's not enough memory. And if you choose IGNORE, and download it anyway, then go to the Configuration Menu on the Panelview, you find that there's LOADS of memory left, you just can't use it because it's "reserved for fonts and bitmaps" (<== this from Rockwell tech supposeort)

... Ahem.
Sorry about the rant.

But again, it goes back to what you are trying to do. You might save memory on one screen by combining bits, but if you have a screen that shows the status of each point in the PLC, you may still need/want to have an individual tag reading the single point.

But that's just Panelviews (and their ilk). Things can get really complex when you move on to SCADAs (Wonderware, et al). In Panelview animations, you animate a single object with a single tag. SCADA-type HMIs allow for multiple types of animation (visabliity, color, position, etc) with calculations based on tag values. There, you usually know your tag count limit, based on the size of the licence, but as I showed above, all sorts of games can be played to reduce the count.

Any more questions?

There are a couple of additional points I will toss out on tags. Please note I'm not a real big HMI guy so some of the power users may take issue with these points.

With the tag-based HMIs I have used so far you can assign any number of HMI tags to the same plc address. In the particular case of the PanelView I don't think you can assign the same HMI tag to multiple buttons, for example a machine stop pushbutton placed on every screen. Each button needs it's own HMI tag. But you can map all the HMI button tags to the same plc address, simplifying the rung structure in the plc.

Another use is "standard" machines with multiple control platforms as options. You can re-reference the tags in the tag database as opposed to doing through all the screens and changing addresses if you change processors. Granted, I've never done this and it may be more complicated than I just stated. But it is a possibility.

Also, as stated earlier, many people prefer to work in the written language as opposed to number systems. 'Winder_Tension_Setpoint' tends to be much more intuitive than 'N7:4'. But with the advent of tag-based plcs this argument pretty much dies.

The way I look at it tags are simply an abstraction. Tags, in theory, would allow one person to program the HMI and another to program the plc without the concern of picking data addresses up front. As long as everyone knew a function or field was required the intimate details of its address don't matter.

Keith

In the particular case of the PanelView I don't think you can assign the same HMI tag to multiple buttons, for example a machine stop pushbutton placed on every screen. Each button needs it's own HMI tag. But you can map all the HMI button tags to the same plc address, simplifying the rung structure in the plc.

Click to expand...

You are correct that you can assign multiple tag names to a single PLC address.

You are also correct that you cannot assign the same HMI tag to multiple buttons - CREATED AS SEPARATE OBJECTS.

However, it is important to note that for your example of a "machine stop" pushbutton on every screen, the identical pushbuttons CAN have the same tag if the pushbutton is created as a Global Object in the PB "object properties".

This may be nit-picking, but I have found that this feature can save much keyboard entry and PV memory.

Phil-

Thanks for the note. I'll definitely use that in the future.

Keith

Just to further refine what Phil said,

...you cannot assign the same HMI WRITE tag to multiple buttons...

The same tag can be used for multiple objects' Read Tags as often as you like.

But as Phil said, if you want to have the same tag be in the Write Tag in more than one object, then you need to make that object a Global Object, and put a copy of the Global object elsewhere.

I am glad this question came up

I guess the history of what tags were "in the old days" helps to understand, I understand P&ID but didnt relate to those tags as the source of this.

Basically "tags" or "tag" is a symbolic text representation of the HMI/SCADA/OP addressing database, which is designed to use alphanumeric "naming" instead of the binary/word addressing that plc's etc use. This will allow many "tags" to look at the data entry for 1 address on a plc. Does this sound like a fair assessment? Am I being too simplistic?

Depending on the software and/or memory capabilities of the device and/or licensing, will govern the number of tags that can be used but can be virtually unlimited.

Feel free to add more but you can bet I am printing this out and taking it to the folder. Thanks.

To take the global object thing a little further. Make sure you make the tag, make it a global object, then copy and paste it or use it a bunch of times or whatever. If you use the tag in several spots, then make one a global object, it will give you a bit of grief.