Tag Based Programming PLC

like to know whether any job vacancy's for Automation Engineer in ur company

hai my friend ,i kike to know whether any job vacany is there for automation Engineer.i am having 3 years exp in Automation Field.if u could please do me that favour if u could........

my contact no: 00971-50-4969755
email id : [email protected]

Thank u
with regards
raghu ram singh .
 
BobB said:
Have had this available for about 4-5 years.
...
That too for the last 4-5 years.

I never said it was new, only that it is a tag-based PLC system that hadn't been mentioned here.

I've been using them for the last couple of years myself.
 
S7 really tag based?

I have been a huge proponent of S7 software in the past. Here comes the but...

My main beefs are:
Even though you can access tags via tag name, really you're still bound by the address. this severely blows if you need to insert a tag somewhere in the middle of a DB or UDT. Everything gets shifted by the size of the inserted tag, and then your code references (because they ultimately point to the address) get Eff'd up. If I'm wrong and Siemens has fixed this somehow, please enlighten me. With RSLogix 5000 this is not the case. A tag is always just a tag name and all of the memory issues are handled internally and flawlessly I might add. So if your UDT needs a new member, you can put it where it makes sense to put it, and not be forced to add it to the end, giving the appearance of sloppy work.

Just my 2 cents.

Bosko
 
bosko said:
I have been a huge proponent of S7 software in the past. Here comes the but...

My main beefs are:
Even though you can access tags via tag name, really you're still bound by the address. this severely blows if you need to insert a tag somewhere in the middle of a DB or UDT. Everything gets shifted by the size of the inserted tag, and then your code references (because they ultimately point to the address) get Eff'd up. If I'm wrong and Siemens has fixed this somehow, please enlighten me. With RSLogix 5000 this is not the case. A tag is always just a tag name and all of the memory issues are handled internally and flawlessly I might add. So if your UDT needs a new member, you can put it where it makes sense to put it, and not be forced to add it to the end, giving the appearance of sloppy work.

Just my 2 cents.

Bosko

You might want to:

Open project > open PLC > up to Blocks > Right click > Object properties > Adress priority > Bottom right selection. (available in S7 5.4)

Never used it, but think that'll be what yer lookin for...
 
Having "grown-up" with A-B PLCs since the mid 80's, I have extensively used both methods.

1. Data-Files in PLC3, PLC5, PLC5/250, and SLC.
2. Tag databases in ControlLogix

For me, it is clear-cut preference for the tag-based ControlLogix.

Most times I don't care how or where the Controller stores my data.

The only reason to have data in a linear "data-table" like structure is when you need to read or write that data to a system that doesn't support the tag-database concept, like SCADA, HMIs, PLC5's, SLCs etc. And for that eventuality ControlLogix provides the Array structures.

Where the tag-based database really scores is when you want to combine elements of different data-types into one data tag, by creating tags based on a "template" data-type that you define (in ControlLogix this is called a UDT - User Defined Type).

I always quote an example of a process/manufacturing "recipe" that may contain many different elements of data, some Integer, some Real, some Flags, some String, etc. I can create my UDT to collect all that different data into one structure, then create my process recipe data tags using that UDT. Now when multiple products are in manufacture, it is a breeze to manipulate the associated product recipes - each is just one tag to copy/move around, instead of multiple sections of data-tables in different areas. I can send the recipe tag to the next controller down the line with one Message instruction, or simply Produce/Consume it over the relevant network.
 
I have done some work on AB ControlLogix and like the UDT arrangement where I can manufacture a data structure w.r.t the functionality/layout of the process/plant to be controlled, referencing the field equipment directly from the physical I/O's. I can then edit, add or remove (conditional) this UDT elements in future to represent the "structure" of the functionality/layout and process/plant. To me, this is a powerful tool.

From Modicon Concept & Unity, according to what's been said here, this is also possible?

What about Siemens S7?
 
Omron too - funny thing is I do not like tag based programming - too slow looking through a drop down list for the tag you want if many are similar. I would like to be able to turn it off.
I program using the I/O numbers directly, although I always have tag based available.
Hence my liking for Omron - no having to type in X or Y, I or Q and the very painful %I.---.---.--- method employed by some manufacturers.
Have programmed automatic power stations with direct numbers when tag based was not available and still prefer it BY FAR as if you are accustomed to it and know all your I/O numbers or have a list or a drawing it is really much, much quicker. Work for myself, time is money/profit (bottles of good red wine - or white).
I lay out my internal I/O the way I want. For eaxample, I use contigious channels for my alarm bits, contigious channels for my alarm muted bits and a bit counter to then allow a compare between total alarms on and total muted bits on. Uneven, turn on the sounder etc etc. Heck of a lot easier.
Hate automatic allocation as it is tagged based and I cannot use the bit count functions as I do not have a clue where the damn program has allocated the bits - certainly not contigiously so I can use it.
Had a race with a Schneider prgrammer writing alarm routines - beat him by a considerable margin - about half the time. He then tried to make excuses for tagged based programming - well then - do not use it.
When copying and pasting my alarm routines, Omron have included a really neat little trick - I do my I/O list in Excel - copy and paste into the symbol list and then turn on the 'add 1 bit number' function in the software. If I have done my tags properly, the adding of a bit number when copying and pasting means I only have to change the alarm input bit number, mute and reset - the rest of the program is written for me by adding 1 bit to the alarm latch, the muted latch etc - how quick is that? Even beats the heck out of FBs for FB lovers - I am not one of them.
When you work for yourself you look for the quickest method. You quote a job and if you can write the program in half the time you make more money. Added to that you are on the next job in half the time and making even more money.
Different when working for a boss - I did once - was never in as much of a hurry as it was his money not mine. I used to try and be elegant and use all these brand new, wizz bang things but no more.
Omron, as well as some others of course, have had automatic allocation and tagged base3d programming available for years now. Used it once - and only once - cost me time and money due to the reasons mentioned above.
Have no desire to go back there by the way.
 
The compelling argument that makes me prefer a Tag-based database over a Data-File collection is that I can create data in a structured fashion that fits the application, not the way the PLC manufacturer wants me to store data.

And the notion of accessing I/O via their physical addresses does absolutely nothing to convey any meaning, unless you attach a "symbol" or other documentation.

The neat way that Logix5000 overcomes this is by the use of Alias Tags. You create another tag in the database, with a suitable and informative name, that is an Alias to the actual I/O data, embedded within the module-defined tags.

With the display configured to show tag alias information, you are left in no doubt, without the burden of having to create additional documentation, the function of the I/O points.

Contrast the attached pairs of rungs. The first of each pair is what you would see if you addressed the I/O directly, and had "data-table" type addresses for the internal flags. The second of each pair addresses the I/O via Alias tags, and meaningful tag-names for the internal flags.

Note that no documentation has been added to any rungs - and they are shown exactly as you would see them if you had to "upload" the processor image (e.g. you don't have the "offline" file).

2010-11-14_174558.jpg 2010-11-14_174629.jpg
 
The UDTs and AOIs in ControlLogix are making it much closer to a C type setup. Now if I can get the UNION function (overlaying two different data structures on a single piece of memory) would be great. The only way I've accomplished this is exporting UDTs and editing the L5K XML files (primarily making enclosing higher level data visible) and re-importing. They become uneditable in Logix but they are useful.
 
Same here - uploaded but with numbers. Just means the PLC can store symbols and descriptions - nothing to do with tag based.
Also note that the software automatically puts and 'I' in front of inputs and a 'Q' in front of outputs. This can be changed to 'X' and 'Y' if that is what you want. That is related to the I/O table stored in the PLC.
The PLC will also store comments if the program is documented that way.
No big deal and no having to put up with tag based to slow me down.

Symbols Uploaded.jpg
 
I had a look at Daba's & BobB's prints.

From Daba's print I can see my plant area and associated physical I/O.
From BobB's print I can see my item name, physical or local address and comments.

I would like to see the layout of the process & plant to be within my controller application, represented as actual plant areas and items within the code. Comments is easier to change than code, and once the comments are gone/changed, the code might look different to a new user.

I know ControlLogix has this ability, not sure about Unity Pro/Concept and Siemens S7.

Anybody a boffin on Profibus & Modbus + ?
 
I think I understand what you are asking
so yes Unity Pro does allow you to organise your code by functional area (select Functional View on the menu bar) then you can create functional areas and assign the relevant routines to those areas. Concept has similar functionality
 
Bernie,

Your refernce to editing the UDT XML file sounds interesting, but I do not think I am following this completely. Do you have an example of what would be possible?

Thanks,

Darren
 

Similar Topics

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...
Replies
37
Views
12,427
I seem to be making this harder than it should be, and Its not making any sense. I simply need to move a real variable to two integer variables...
Replies
8
Views
992
Hello, I am upgrading some custom AOI's for a customer that was using plantpax 3.5 they are moving to Pax v5. In their old AOI's they were...
Replies
0
Views
540
Good afternoon everyone. Just starting to use Logix based tag alarms, and I am likely a little confused. What I would like to do: Use Logix 33...
Replies
5
Views
1,870
Hi all, We have been using an UDT that contains tag-based alarms as an In/Out parameter for an AOI. (V31-V32) Unfortunately, V33, they have...
Replies
0
Views
1,101
Back
Top Bottom