Tag based programming - worth it or not

I have just finished a project where the software was designed strictly for tag based programming. The most painful experience of my life and so slow to program and commission! It took me at least 2-3 as long to program the job as I usually do using a keyboard and typing in I/O numbers.

I was also speaking with an engineer from one of my clients (NASA) and he was telling me that the Europeans tried to introduce it 15 years ago and everyone told them to go jump. He agrees with me that it is painfully slow and takes at least twice as long to program as usual. As he said, and I agree, one tries to make meaningful tags and finishes up with a tag a mile long with lots of underscores and the whole thing becomes a nightmare. I was doing some software and commissioning at their premises using Omron CX-Programmer and he was really impressed at how quickly and easily I was able to program and commission the job - no tag based stuff at all! The man has programmed many brands of PLC in the past and is aware of how important ease of use and speed is to me. We commissioned a diesel generator power station with soft transfer, power failure mode and peak lopping in 9 hours and he was with me the whole way. I wrote the software for the whole job in 3 days.

I would particularly like to hear comments from people who program for a living, have to quote a job and stick by the price, with respect to their feelings about this painfully slow tag based software that is hitting the deck in large lumps lately. In other words professional programmers who have to get the software done, get the commissioning done very rapidly, sometimes to unreasonable deadlines, make a $ and get on with the next job.

For people working in a factory environment it may be useful for troubleshooting but my personal opinion is it is a PITAS to everyone who is trying to get a job done in a hurry, whether it be a new job or maintenance - just to slow for mine.

I am currently considering rejecting jobs that use tag based software as it takes too much of my time and makes it very hard to earn a $! That includes Sysmac Studio from my favourite supplier Omro - it is painfully slow to program. I think many manufacturers are getting sucked in by the PLC Open crowd to be honest, and the Europeans!

I do not want this to become a manufacturer bashing exercise either - just opinions, good and bad, about tag based programming. Obviously I have already made up my mind from losing money on a job (quite an amount too) as I had to quote the job and there were no extras for having to work with painful software that wasted so much of my time. I have deliberately not mentioned the brand either - many will know the manufacturers (quite a few) who have opted to go in this direction, sadly!

Bob - First a suggestion why not make the tags the io address then you can just type in the address (tag), or use really short tags eg 'I1'. So that should be as fast or even faster than typing in the whole address. Create a spreadsheet at the start of the project with all the IO addresses and create the tags based on the address (should be a 10 minute job)
And now my opinion, for me tag based is the only way to go for the following reasons:
- I will often have the code written well before the io layout has been finalised, easy with a tag based system.
- Code is definitely more transferable, I can copy a section of code from one program to another easily
- When dealing with internal bits and registers it is much less work if I don't need to assign addresses, just type in a tag and let the system worry about where it stores the data
- Grouping of tags makes diagnostics much simpler, eg if I want all the tags for say Pump1 I filter for tags starting with Pump1 and then I will have a list of all the data associated with that device (io, memory and scada
- The plc tags can be the same as the scada tags
- Creation of a tag (at least in Schneider plcs) is simple (use required tag in program and if it doesn't already exist right click create tag). Although I would normally at the start of the project create all my io tags in a spreadsheet and import
- The finished program is far more 'readable' with meaningful tags than just addresses
- Upgrading (replacing cpus or even whole systems) is an easy job if it was a tag based system. Not so with an address based system, trying to transfer all the addresses within a program to a new addressing arrangement is a nightmare

I started programming using addressed based systems (5TI, Modicon 184, etc) and have gladly welcomed tag based systems. I am confident I can deliver large projects far faster than if I was forced to use an addressed based system.

While this is not tag based programming in the truest sense of the word, I have always used the CX Programmer symbol table and instruction commenting heavily to document programs.
In the cases where I have multiple PLCs connected to the system, I always duplicate the shared symbols on all the PLCs so that they match between the separate programs.
I find it is much easier to debug and support programs that are heavily documented, particularly when dealing with customer support personnel and after the system is several years old.
The attached PDF is one network from a program being delivered to the customer this week and is typical of the way I document programs.

I have found a few things that make tags quicker for me and a few of my customers. I use all LOWER_CASE_LETTERS for real world tags (inputs and outputs). HMI_TAGS have tbe same names in the PLC as well as the HMI. I use lower_case_letters for internal tags.

I have seen a few guys use DI_START_PB for inputs or DO_MOTOR for outputs. ib_tag for an internal bit, ir_tag for internal real, id_tag internal dint.

I can use my standard pump logic for tank level control over and over. There is a few tricks that you have to learn if you do similar jobs. They are called UDT (ueer defined tags) using these help you organize tags so they are always very easy organize.
A simple example
TANK_404.HIGH_HIGH_LIMIT (real world switch)
TANK_404.HIGH_LIMIT(real world switch)
TANK_404.LOW_LIMIT (real world switch)
TANK_404.LOW_LOW_LIMIT (real world switch)
TANK_404. LEVEL (real world analog level)
TANK_404.high_high_alarm (setpoint when using analog level)
TANK_404. high_alarm (setpoint when using analog level)
TANK_404. low_alarm (setpoint when using analog level)
TANK_404.low_low_alarm (setpoint when using analog level)
TANK_404.MOL (real world input for motor overload)
TANK_404.AMPS ( real world current when using a drive or current rings)
TANK_404.amp_alarm ( setpoint when using a drive or current rings)

As you can see my tag is TANK_404 the rest of them are inside a UDT. I can spend a few minutes making a UDT and this way I can create a tag just like a normal tag and call it a TANK instead of a DINT, BIT, SINT, REAL, etc.
Now when you use the tank high high limit to stop the entire system you just type in TANK_404 and select the tag fom the drop down menu. This list has just the tags inside the TANK_404 UDT not the entire list of tags.
you can also export LOGIC. Thus ca. Be a huge time saver.a fww examples. A simple start stop is not a time saver. A vacuum application that has a 50 rungs of logic each. I did a system that had 16 vacuum pumps. A created a UDT and used it the vacuum logic. Once I had the logic finalized on the first pump I did a simple copy and replaced the TANK_1_VACUUM with TANK_2_VACUUM my next tanm was done. I then repeated this for the rest of the 16 tanks. My logic was done and standardized now.
When I try to do this with address based programming it takes a lot of spreadsheet work for me to make this work.
Someone will probably say I should use a AOI but that is another story for another day.
Hopefully this makes some sense and might be able to help you.

BobB said:

I have just finished a project where the software was designed strictly for tag based programming. The most painful experience of my life and so slow to program and commission!

Click to expand...

Why? You could be slow or the PC could be slow or the PLC could be slow. I have never had a problem with tag based software but I don't work on big programs.

I was also speaking with an engineer from one of my clients (NASA) and he was telling me that the Europeans tried to introduce it 15 years ago and everyone told them to go jump. He agrees with me that it is painfully slow and takes at least twice as long to program as usual. As he said, and I agree, one tries to make meaningful tags and finishes up with a tag a mile long with lots of underscores and the whole thing becomes a nightmare.

Click to expand...

I try to keep the tags short.

I would particularly like to hear comments from people who program for a living, have to quote a job and stick by the price, with respect to their feelings about this painfully slow tag based software that is hitting the deck in large lumps lately. In other words professional programmers who have to get the software done, get the commissioning done very rapidly, sometimes to unreasonable deadlines, make a $ and get on with the next job.

Click to expand...

That isn't me,

I do not want this to become a manufacturer bashing exercise either - just opinions, good and bad, about tag based programming.

Click to expand...

But maybe it should be. Think of the big data base of strings you must have. What if the PLC software is crude and does linear searches through the database instead of more advanced techniques. What if the sorting is done with a bubble sort instead of faster sorting methods. Does Omron divide projects into programs that can be compiled and downloaded individually or is the project one big file that must be downloaded all at once so every time a small change is made the WHOLE project must be compiled and the data base regenerated.

Step7 can download FCs, FBs, and DBs one at a time. Rockwell can update 1 rung at a time. Does anybody think they are slow when using tags?

What if the marketing team for Omron felt they had to have tag based programming so they rushed the programmer to do the minimum required just so they can say me too. We have seen this when it comes to auto tuning in motion control.

Sorry I could not disagree more.
I started program using Medoc and then onto Rs 500 first dos based then windows based. Now that I use S7 and Logix 5000 and the odd time have to dip back to rs 500 I remember how slow programming using address based system can be. I found on projects that the best way was to keep a excal sheet of address and this worked very well until the pressure was really on to get something working or someone else came in to work on it.
Like Jeff I use much the same system but I would use this with AOI also or FB in S7.
I also feel it makes it easier when you are using different plc software as you are not trying to remember the different address types.
I also feel it makes it easier for someone new learning plcs not to have to learn about in

AB terms T4, C5, B3, N7, F8,s:15/1,Slots, Racks, Groups ,
Siemens DBX.DB10 etc
Mits M100,M8000( always on bit), C542 (high speed counter)T,
TELMAC %m etc

Now Start_Button in ever plc means start button.
It is down to the programmer or programmers on the project.

Just my feeling

Donnchadh

Bob, you are not alone in your frustration. There is at least one other guy who feels EXACTLY the same way. Me. As someone who has to program a variety of brands, I have an extremely difficult time with tag-based programming.

My first introduction was ADs 'Productivity3000' PAC about 4 years ago. Took me a while to wrap my head around it, but in the end, it wasn't all that horrible. I actually revisited that project quite recently for a few modifications, and it went smoothly.

Probably 2 years ago, I had my first customer request for a CLX. A short time into the project, I was completely overwhelmed, and ended up outsourcing the programming. From then on, I have shied away from CLX jobs, and continue to outsource the programming on those that I can't turn down. I have no issue debugging or making changes, but writing from scratch is too much for me. Thankfully, the programmer I use is really good.

I guess I like having everything predefined. I've been at this 'a while', and that's how its always been. I am comfortable with it. I like organizing by groups. I can set aside ranges for similar items. I realize that I can group things by tag name, and in theory, it should make a lot more sense. I think my biggest difficulty is that I don't deal with tag-based programming on a daily basis. To me, it's just a lot of extra work to organize everything up front. With predefined registers, that's already done for me!...

Looks like it's not going away, so I'm sure I'll eventually figure out how to make sense of it. I do realize that it's actually a better method, and there are huge benefits, but I'm just so used to 'the old way' that its tough to make the switch.

On an unrelated topic, I don't think I'll ever understand why an asynchronous scan is better than a synchronous one...



-Eric

Eric I think async vs sync is because of all the remote I/O network mistakes that people can make. Think of the "just because you can doesn't mean you should". I can bridge between Dnet to Cnet over an Enet connection with huge amounts of delays from interscans and RPI etc.

Plus I am sure it is easier for AB to just say "this is how it is." We can shave months or years off the development time by make the I/O update out of sync.

Bob, Eric
Just a question, when you program 'address-based' PLC's, do you then name the address with a 'symbol'?
I know Omron & RS500 both have this option, as well as the description field.
Whilst this is not true tag-based addressing, it is the same thing, with the exception that you do not have to allocate the Symbol (Tag) to an address.

In a lot of plants/process that we work in, tags in the code are representative of the PID tag & the final wiring label. This makes things so much easier for everyone when trying to understand a process, troubleshoot a problem.
After all, the PID/equipment list has unique items, why should they not be in the PLC?

SCADA is the same, you have to put a unique tag in there. What do you name your tags in your SCADA system?


Also, with the UDT based structures that are now available, whilst the initial setup takes a bit of time, the overall addition of future devices is so much faster.


Like Donnach, I also started with Medoc & TI, where to make things readable, you had to keep the tag/Symbol structured.
All tag names should try to follow this pattern, otherwise the code makes things un-readable.
Rather than Suction_Pump_1_AutoStart, why not P1_AS? Much simpler & easier to make consistent.

Interesting comments gents.

1) You are right Geoff but I had my customer driving the 'meaningful' tags on this one. PLC number, floor number, switch room number, switch board number, cell or CB number, destination number - drove me nuts!

2) On large jobs I always use Excel to create my tags and then just highlight them and copy and paste them straight into the software - if I have made a mistake or there is a tag already defined the software tells me and asks if I wish to modify those tags before pasting them in.

3) Copying and pasting tags from one PLC program to another is just that - copy and paste - all the PLC programs are in the same tree anyway so it is really easy, or open a second copy of the programming software and copy and paste that way.

4) If using a SCADA (usually Citect) I just have 2 copies of Excel open and copy and paste as I wish anyway.

5) Citect still requires the real address anyway - not sure with Schneider PLCs though (I was not using Schneider on this job). Some PLC software only has an import/export function for tags and this becomes an absolute pain as well - what ever happened to copy and paste?

6) The descriptions are detailed and very readable.

7) When upgrading to another PLC with different addressing not a problem - copy into Excel and use the replace function. My Omron software automatically converts to a new PLC anyway.

8) As I generally do all my own design work as well I know exactly what the I/O layout is and allocate accordingly.

Mendosys - you are correct but your example also shows the I/O address (numbers) and a meaningful description - that is the important thing to me - meaningful description. The point commenting in CX-P is very good also - as you have shown.

Jeff - I can still write tags that way - in Excel of course - but still use the I/O numbers for input - much quicker. I do not generally use UDTs or FBs as there is no repeatable code (with very few exceptions) that I can use from job to job. The only thing that I normally use that is repeatable is some comms and maths routines for extracting and calculating data from say Caterpillar engines and I have a standard routine that I copy and paste but it is all in floating point ladder - see what I get from the engine (they are all different) and cut what is not there - easy.

Peter

1) I am not slow and neither is the PC or the software I normally use - the slowest part is the Ethernet comms on a large project with, say, 10 to 20 PLCs - online programming and monitoring of that many PLCs chokes the Ethernet to not much better than serial comms. The next slowest thing is typing in tags with heaps of underscores to delineate what everything is for - shame that could not be automated (very tongue in cheek).

2) It was customer driven and a PITA!

3) Omron CX-P has excellent online programming facilities which I use all the time. Additionally separate sections can be downloaded - that is not my issue. CX-P allows additions of tags online. Sysmac Studio also allows changing of tags online - that is also not my issue. Some other tag based systems allow the changing of tags online as well. Much care needed there though.

4) If you have a look around many PLCs are going strictly tag based and that slows me down.

Donnchadh - I agree that stop_button is easy to remember but I find I/O numbers just as easy. With Omron CX-P you can use either tags or I/O numbers - the best of both worlds. I rarely ever look for a tag though and just use I/O numbers. I allocate my I/O numbers from the start of the job as I generally do all my own design work as well - some exceptions as I do software for others but have them trained in how I want things and then it is easy. With my favourite software if I wish to use input channel 100 bit 11 I just type in 10011 and the software looks after the dot - I do not have to type in anything else. Same applies to registers.

Eric, I have no issue with people using tag based software but would just like to be able to do it my way as well - as I currently do. I have a choice of using either. I also like to be able to allocate where I want things in the PLC memory map. I currently have a choice and can place everything into contigious areas of the memory map, this includes remote I/O as I can set a remote I/O card to software configuration and do what I wish. I have not used CLX to date - last AB job I did was SLC500 - yes - all those memory areas drove me nuts too!

Jeff, I can bridge from one network to another with Omron easily - just use a routing table. I also find that with Ethernet IP and Omron I just set up an automatic, or manual, network allocation table from PLC to PLC and it all just happens seamlessly if there is a lot on networking. Networking on this last project was also too hard and took ages. You can probably see why I have not mentioned the PLC brand as I did not want to start world war III.

Oh, one other things I should mention is that currently I can set up automatic increment if I wish when copying and pasting say alarm routines and the software automatically increments all the I/O addresses by one - that saves a heap of time too.

I guess I will probably be accused of being a GOB (grumpy old B) and not wanting to get with it but that is not the issue - I just look for speed and ease in getting the job done, make a $ and get on with the next job. I do not like losing a $ even it it is just my time - the problem is that if I lose time I lose money by not getting the next job done.

Thank you all for your comments so far - I hope people will find the information in the thread useful and helpful.

And please do not think I am using this thread as a sales push for Omron - just using the software as an example of what I find is speedy and to my liking.

I guess different people from different companies writing different PLC programming software have their own thoughts on how things should be done. Shame they did not ask there customers though from time to time.

Ah lostcontrol - I was typing when you posted.
I name everything with a symbol but still find it slower than using I/O addresses.

I name my digital inputs in the SCADA DIG1, DIG2 etc analogues AN1, ANB2 etc - then a meaningful description that is copied and pasted from my PLC tag database in Excel - several copies of Excel open on different screens - I currently have 3 screens attached to my PC to allow this and I do not have to constantly change from spread sheet to spread sheet on the same screen - just go from one screen to another. Most useful when you are using several copies of Excel, Word, PLC software. SCADA etc all open at once and copying and pasting between them.

I started with the old Hitachi and Square D black boxes and many other old dinasours. Medoc too - never used TI.

I prefer tag based programming myself. ControlLogix you have no choice, with Siemens I always change to tag priority programming before I start.

As someone mentioned above, UDT's are a godsend and I set these up to ease the programming and manage data structures.

For large scale programming auto-generation of the code is a good which can only be done if your programming tag based.

PeterW I have seen several large conveyor projects auto generated. They where slc 500. It can be done it typically doesn't look as clean though

Thank you BobB for posting this. A lot of good information coming from the fella's with experience. I struggle with this also. Thanks guys for all your good tips here.

lostcontrol said:

Bob, Eric
Just a question, when you program 'address-based' PLC's, do you then name the address with a 'symbol'?
I know Omron & RS500 both have this option, as well as the description field.
Whilst this is not true tag-based addressing, it is the same thing, with the exception that you do not have to allocate the Symbol (Tag) to an address.

Click to expand...

I get your point, and I do name addresses with symbols, but normally only the internal addresses that I use often. I do this more as a quick reference across brands though. For example, in AD, my 'RESET' bit is usually C35, in AB, it's B3:0/15. When I associate that symbol, I can just type 'RESET' without having to remember what bit it is in that brand.

To be honest, for me it's mostly just a resistance to change. Over the years, I have had to learn all the differences between many brands. I jump back and forth all the time, depending on what the customer wants. The main difference was simply the prefix used (M, N, B, Q, C, etc.), but the addresses already exist. With tag-based, there are no restrictions. I can name them whatever I want. This should be a plus, but for me, it somehow makes it more difficult.

A (rather poor) analogy of how I see it...

1.) Someone gives me 100 bins. Each group of 10 bins is painted a different color. Black, Brown, Red, Orange, Yellow, Green, Blue, Violet, Gray, and White. Each bin in the group has a number from 1 to 10. I will have NO trouble organizing my parts into these bins, and I will easily remember what parts are in what bins...

2.) Someone gives me an unlimited number of bins, and I can paint each of them any color of the rainbow. Now I can't even get started...

That's just how my mind works...



-Eric