Tag based programming - worth it or not

[kku]

We use a machine from Germany that is programmed strictly using 'tags'. This machine is a nightmare to troubleshoot because the tags are extremely long with underscores and multiple words. So unless you programmed it you have no idea what the tag is really for. Sometimes the tags are descriptions that don't really make sense or are very similar to other tags. So if you are not careful you end up looking at the wrong tag in the wrong section. To make matters worst the software screen splits vertically in half when you are online. So you are constantly scrolling to see the entire tag name.

They also have a lot of function blocks in the program. They tend to build massive function blocks with multiple functions. Often only one or two functions for the function block is used. Then they have nested function blocks with three levels. So I am often sitting there figuring out what the functino block is actually used for. Of course the function block instance is generic and doesn't describe why it's there for this particular case.

So I haven't been a fan of function blocks or tag based programming. Although I now believe that this particular implementation was the problem. If they had defined the tags more simply and made function blocks that only focused on one function then perhaps it will be better. This is now how I try to write function blocks.

 

[jkerekes]

Obviously its possible to write confusing programs using either tag or memory based PLCs. No mystery there. Anyone can misapply the tools they are given. Just because you can use the software, it doesn't make you a programmer. Its a skill that needs to be learned. I much prefer tag based programming for all the reasons already discussed. Much easier to create and maintain.

 

[kku]

Obviously its possible to write confusing programs using either tag or memory based PLCs. No mystery there. Anyone can misapply the tools they are given. Just because you can use the software, it doesn't make you a programmer. Its a skill that needs to be learned. I much prefer tag based programming for all the reasons already discussed. Much easier to create and maintain.

I guess I should have added comments to the original question. I am good at going off track especially when I am 'venting'.

My initial exposure to tag based programming because of this German machine was very poor. I was cursing at it constantly. Now that I am 'older' with some more experience. I can see the benefits for tag based programming (and function blocks) for reusability. Unfortunately I haven't had to use it much. Our standard platform is still CX-Programmer.

 

[Paullys50]

...
I sometimes wish I was in the mainstream and could use FBs effectively for repeated code, UDTs for setting up some of the fancy stuff and saving time but I am not there. Every job is quite different and there is, generally, no re-usable code.

I am surprised at this comment "generally, no re-usable code". I completely understand that projects and process' vary and as such code variances will always be required to some extent, however if you have a good structure I feel you should be-able to reuse it from process to process as structure and user-defined tags (UDTs) should be useful across most projects. After all analog inputs are similar, digital inputs are similar, device controls (pump, light, valve..) is similar across projects so portions of your code should be the same. Scaling, Manual/Automatic control, step sequencing? Most of these items with tag-based referencing can easily be standardized (bare with me, I specialize in Rockwell products so I'm speaking with a bit of ignorance towards other platforms).

Bare in-mind, all of these concepts can be achieved both with direct memory addressing and tag referencing, it's really about defining structure across your projects.

I find tag-based programming keeps things fluid across all aspects of a project. P&ID drawings, Electrical Drawings, Process/Functional descriptions, SCADA and the PLC code all flow together. If there is a motor reference on the P&ID called M-101, that same reference is used in the functional descriptions, it is then shown as M-101 on the SCADA screens, as such it ends up as "M101" in the PLC code. I no longer have to translate M-101 to B3:0/0, or N7:0. Makes communicating with non-Controls engineers much easier as I don't have to decrypt the physical objects of my system with meaningless memory locations in the PLC. With Udt's and standardization of logic I know that for all motors I have the following characteristics:

Start
Stop
Forward
Reverse
Speed
Fault
Manual
Output
...

Create an Add On Instruction and my motor control never has to be rebuilt. Stays the same from project to project and It's very easy to read.

Same with my general control. I know I will always need a start, stop, hold, abort, step time, step number...etc in my code no matter the project, so standardizing a control UDT works very well. Plus it is clear to others who may not be familiar with my code, which features exist in the code. And with the Logix platform intellisense works as Peter had mentioned, and speeds up my programming time substantially.

I think the trouble people get into is defining the structure as it's no longer defined for you, there is additional thought to put into a program. I experienced this first hand with a new machine I had to support years ago (just out of college). Looking back it's obvious the OEM was green with the ControlLogix platform and the concept of "tags". It was ugly, and it was ugly because they created tags on the fly, versus using UDTs and drafting a tag structure. For instance, I would see inconsistency in the same programming reference:

Ht_Zone_1_Start
Heat_Zn2_Start
Ht_Skid3_Start
Heat_Skid_4_start

Those tags all did the same control in a different part of the machine, however the tags were so inconsistent it made the code a nightmare to work with. This was all over the place. Had they used a UDT structure, and defined it well, constancy is in place and tags can be shorter.

Zn1.Heat.Start
Zn2.Heat.Start
Zn3.Heat.Start
Zn4.Heat.Start

Because these 4 zones did the exact same thing you can easily copy/paste and do a find replace, using the UDT which saves time. Try to use find/replace on the sloppy example, or just when looking at the code, it's much easier to see a typo using the UDT then the previous. I did have instances where I had to correct the same tag reference typed differently, as such the engineer could not keep track of the tags he had already created and referenced versus what he needed to program. So "Ht_Zone_1_Start" appeared in places, then "Heat_Zone_1_Start" appears as well. He got lost due to his lack of a thought-out structure.

Another consideration, at least for the Logix platform are the use of program tags. You can use program tags and use the same reference for each zone:

Program: Zone1_Heat
Heat.Start - Alias for - Zn1.Heat.Start

Program: Zone2_Heat
Heat.Start - Alias for - Zn2.Heat.Start

Program: Zone3_Heat
Heat.Start - Alias for - Zn3.Heat.Start

Program: Zone4_Heat
Heat.Start - Alias for - Zn4.Heat.Start

Now you can finish the first heat program, completely test it then export the program as a "template" then you can import that code for the other 3 heating zones just change the alias of the program tag and those 4 heating zones are now programmed and tested. This also allows you to copy/paste from program to program without messing with tags. You make a correction for program 1, copy/paste to the others and the tags update automatically.

Once you have a defined tag structure, you can auto-generate code, tags, alias, descriptions...etc just like you my have done previously, but it only works if your structure is well defined.

More long winded than I expected, sorry if it sounds like a ramble!

 

[Eric Nelson]

edit: Maybe BobB by Tag-based means the difference between classical memory assignment in fixed blocks (AB PLC5 N-files, F-files, B-files, etc.. Siemens Merker, Timer, Counter files) as opposed to newer PLCs where you create memory files that contains a structure of the needed data (BOOLs, INTs, REALS, TIMERs etc. within the same file).

Not sure about Bob, but this is definitely what I was referring to.

More long winded than I expected, sorry if it sounds like a ramble!

Not at all, this is GREAT info! (at least for me!)... :site:



-Eric

 

[kamenges]

Originally posted by Brijm:

One of the things I did find, when starting to use a tag based platform, is that I had to come up with a system, to consistently name the tags.[/b]

This is a big point. One of the reasons people like fixed addresses is they force a macro->micro definition structure. You start from the largest sub-group and work toward the smallest. Always. Without exception. It makes it easy to burrow in on a single item, especially if you have some type of upper-level conceptual structure in mind when you start. If you define your tagnames the same way things will be much less confusing. This same thing has been said many times in different ways in this thread. But that is because it is vitally important to using tags in a useful manner. Structure your tagnames in a consistent way and they are easy to find and enter.

Keith

 

[JeffKiper]

OK forget everything I tries to say in multiple post. Keith said it in one short and sweet post.

 

[pacak]

Hi there!

I used to work in several maintenance departments before starting to work for machine builders, and I have to tell that for me a well documented program was the most important thing!

In my oppinion, with tag based programming it is much more easier to achive that.
Definietly it is a step forward. However, the manufacturers should let us to choose!


P.S.:
What happens when we will start writing control code in xml instead of ladder, and the client will choose the PLC brand from our webpage before comissioning?