RSLogix5000 tagnames

[tspisak 0]

Does anyone have RSlogix5000 tagname standards that they could post?

[Chris Elston 78]

I would follow my normal standard. Shown here: http://www.mrplc.com/kb/index.php?page=ind...x_v2&id=25&c=11 Just a thought... NFPA 79 2002 Edition reference Table E.1 Device and Component Designations ABE Alarm or Annunciator Bell ABU Alarm or Annunciator Buzzer AH Alarm or Annunciator Horn AM Ammeter AT Autotransformer CAP Capacitor CB Circuit Breaker CI Circuit Interrupter CNC Computerized Numerical Controller CON Contractor COs Cable-Operated (Emergency) Switch CPU Central Processing Unit CR Control Relay CRA Control Relay, Automatic CRH Control Relay, Manual CRL Control Relay, Latch CRM Control Relay, Master CRT Cathode Ray Tube, Monitor or Video Display Unit CRU Control Relay, Unlatch CS Cam Switch CT Current Transformer CTR Counter D Diode DISC Disconnect Switch DISP Display DR Drive EMO Emergency (Machine) Off Device END Encoder ESTOP Emergency Stop FLD Field FLS Flow Switch FS Float Switch FTS Foot Switch FU Fuse GEN Generator GRD, GND Ground GUI Graphical User Interface HM Hour Meter HTR Heating Element IC Integrated Circuit INST Instrument IOL Instantaneous Overload I/O Input/Output Device L Inductor LED Light Emitting Diode LS Limit Switch LT Pilot Light LVDT Linear Variable Differential Transformer M Motor Starter MD Motion Detector MF Motor Starter ΠForward MG Motor ΠGenerator MR Motor Starter ΠReverse MTR Motor OIT Operator Interface Terminal OL Overload Relay PB Pushbutton PBL Pushbutton, Illuminated PC Personal Computer PCB Printed Circuit Board PEC Photoelectric Device PL Plug PLC Programmable Logic Controller POT Potentiometer PRS Proximity Switch PS Pressure Switch PWS Power Supply Q Transistor QTM Thermistor REC Rectifier RECP Receptacle RES Resistor RH Rheostat S Switch SCR Silicon Controlled Rectifier SOL Solenoid SNSR Sensor SS Selector Switch SSL Selector Switch, Illuminated SSR Solid State Relay ST Saturable Transformer SUP Suppressor SYN Synchro or Resolver T Transformer TACH Tachometer Generator TAS Temperature-Actuated Switch TB Terminal Block T/C Thermocouple TR Timer Relay TSDR Transducer TWS Thumbwheel Switch V Electronic Tube VAR Varistor VM Voltmeter VR Voltage Regulator VS Vacuum Switch WLT Worklight WM Wattmeter X Reactor ZSS Zero Speed Switch

[TimWilborne 108]

Personally if feel the whole advantage of RS5000 is that you dont have to use these structured symbols. I would name them something that makes sense without having to look it up in a set of standards. At first I had a very hard time changing to RS5000 because of the lack of structure. But it actually allows you to structure you data better once you get used to it. I would put the data into user defined tags. This gives you structure but allows you to mix different data types

[Chris Elston 78]

Well you've got me interested...explain what you do with your tags?

[TimWilborne 108]

Here is a portion of one of our user defined data types. Sorry for the bad paste. Couldnt figure out how to paste like a spreadsheet.I have pasted another one at the bottom which may be easier to follow why if feel it makes programing easier. It has bool tags for auto, manual, etc. The in and out are the sequencer inputs and output. The InArray and OutArray are what the sequencer pulls from. The Diag is an XOR or the In and the InArray at the Conrol.pos. After that is the shift information tags. It mainly allows me to group tags that are alike together even though they may be different data types. AutoMode BOOL Decimal ManualMode BOOL Decimal InCycle BOOL Decimal CycleComplete BOOL Decimal CountComplete BOOL Decimal Internal DINT Decimal Timers TIMER[20] Counters COUNTER[20] Control CONTROL In DINT Binary Out DINT Binary Diag DINT Binary InArray DINT[20] Binary OutArray DINT[20] Binary PartsCurrent COUNTER Parts1stShift COUNTER Parts2ndShift COUNTER Runtime1stShift TIMER Runtime2ndShift TIMER PartsLifetime COUNTER CycleTime TIMER Running1stShift BOOL Decimal Running2ndShift BOOL Decimal Motion MOTION_INSTRUCTION[20] PositionRaw REAL Float ******************NEXT EXAMPLE*********************** These are some of the parameters for different parts. If there are 10 different types of parts and the data type is named settings, i just create a tag named settings[10]. Then i can indirectly address the different elements to change the parameters the machine is running. If i need to adjust the Hold down advance parameter, it is very easy to find compared to traditional symbols Velocity REAL Float Accel REAL Float Decel REAL Float HoldDownAdvance DINT Decimal HoldDownRetract DINT Decimal BlocksAdvance DINT Decimal BlocksRetract DINT Decimal CycleTime DINT Decimal AccelerationFeedForwardGain REAL Float AverageVelocityTimebase REAL Float FrictionCompensation REAL Float MaximumAcceleration REAL Float MaximumDeceleration REAL Float MaximumSpeed REAL Float OutputLPFilterBandwidth REAL Float OutputLimit REAL Float

[darrenj 0]

I agree with TW. I make my tags descriptive..I know its a memory hog but it makes life easier than referning to seperate sheets to figure out what LS243 Is..An example of mine North_west_door_switch (Bool) Analog_main_tank_pressure You can go to a program in the middle of the night without any documention and still follow the program..If North_west_door_switch is stopping the machine from running you know where it is..a whole lot easier than trying to figure out LS243 Just my opinion D

[Spedley 0]

I only use tags with RSLogix so I usually don't (usually) care wether it's a solenoid or motor or whatever. If I use symbols I use my own method (or maybe other peoples aswell) of giving a description e.g. Right Hand Table Lowered and give it the symbol RHT_L for inputs and Lower Right Hand Table and give it the symbol L_RHT for outputs. Because I think comments are absolutely neccassary and symbols are just and easy way of remembering addresses they don't need to be useful to anyone else and because the comment is easy to remember I never forget the symbol Edited 11 Oct 2005 by Spedley

[TimWilborne 108]

chakorules, whats your opinion on this method

[PLCMaster 0]

Any decent programmer will tell you comments are what make a program easy to understand rather than symbols or tags. Once you begin to get into tag aliasing and multiple axis motion control, tag names become irrelivent and comments become the most important thing . I work on the ideal that anybody who has the ability to jump online with RSLogix5000 must be able to decipher the program and diagnose a fault within minutes. As long as you give your routines descriptive names for their given actions , comments are all you should need . Edited 1 Nov 2005 by PLCMaster

[Chris Elston 78]

I use TAGS and DESCRIPTIONS. I think both are important. Like I said here: http://www.mrplc.com/kb/index.php?page=ind...x_v2&id=25&c=11 "If you haven’t already noticed, I am still young and “wet behind the ears” as the older PLC gurus might say. However one thing I noticed that separates us younger programmers from older generation PLC programmers is how they don’t use symbols. Well most of them don’t that I’ve personally been around. Have you ever looked at a PLC program that was written a while ago, or maybe more recently written by the older programmers? What’s missing? Better yet, how do they remember all that stuff? I am not really sure how “they” remember all those bit numbers and what they mean. How can anyone remember that B3:1/1 means “system is running” or I:1.0/3 means “proximity transfer is extended”? Either I need to work on my memory skills or I think I feel more comfortable remembering a symbol name when I program." I feel both a tag name and a description are important. I used EXCEL to import my tags into my PLC. Because I use EXCEL, it so easy to include both. If you enter them one at a time while you are writing PLC code, I think you should stop doing it this way and start looking at ways to save you some time by using EXCEL to manage all your tags and descriptions. You can look at any of my programs and see my examples: http://forums.mrplc.com/index.php?act=Downl...thor=chakorules I've seen some programs with no descriptions, but the problem I have with those is I don't understand the short hand they used. Just because they used short hand to create symbols, doesn't mean I would understand that "LT" could mean "light tower" or it could mean "light". Having the description is important that helps decipher short hand symbol names. On the other hand, I see programs with no symbols, and because I am a symbol programmer this drives me nuts. I can’t remember that B3/1 means “system running”, so I create a symbol name “RUNNING”. I can remember that I want the bit that means running, so I type it out as “RUNNING” rather than remember that B3/1 means running. I think this is the difference between older and younger generation PLC programmers. I have to hand it to the old guys though. The older guys can take an old PLC program and UPLOAD IT without any descriptions and debug it. That’s because that is what they are use to doing and remember bits directly. I can do the same, only I will start labeling common bits with symbols as I learn from the upload. I can still do the same, but takes me longer to decipher and uploaded programmed with no descriptions and no symbols, because I will start labeling each bit as I learn what it does.

[TConnolly 13]

I agree with Chakorules here. Generally for internal tags I will use a descriptive tag name. But for IO, my tagname ALWAYS matches the tag name of the device on the electrical drawing or P&ID. Additional descriptive text can be appended when needed. Such a tag (ISA) might look like: ZSC1505_MovIsClosed

[TimWilborne 108]

Let me clarify a few things. The original question was As far as this long spill about new versus old programmers. First of all, if both of our birth dates are correct, I am a few years younger than you. And I have found that the older programmers use these structured symbols more. They do put them in the description instead of the symbol name and no I have no clue how they remember what B3:0/7 is either. I have always felt that they did this to keep there programs a little harder to read so they would have to be called in for maintainence work. I agree that descriptions are good but why not go ahead and put them in these user defined data types or atleast the tag name so you can spell out what you are looking for instead of using these symbols. Plus most people vary from the standards and end up with their own. Is PS a pressure switch, prox switch, position servo, or a print server. The programmer is going to use PS for which ever one they use the most. This can get as bad as trying to read the newspaper classifieds. Why not just spell out PressureSwitch or ProxSwitch in you tag name As a younger programmer, I would feel you would be more for this new symbolic addressing. How many times have you heard people complain that they wish AB would make it so the descripters could be uploaded to the processor. If you use the tag names correctly, you can with RS5000. I just looked at one of my larger programs and it bearly as any descriptions for tags. The description is the tag name. Plus as I said earlier, if you spell out you tags in a user defined tag, you can structure your tags better because you can mix different data types

[Chris Elston 78]

I probably don't really have a position to give an opinion about what you are trying to describe about RS5000. Mainly because I've only used RS500 with Allen Bradley. However I have used similar software packages with other PLCs that store tags in the PLC. So I can only make judgment by other PLC brands and how other software packages behave. I dunno if when I say symbol and you say tag is that is the same or different. Our terminology might be different. So I have posted a screen shot. The GREEN colored text in RS500 is a symbol or I could call that a tag too. Maybe that is different in RS5000, I don't know for sure. But when I say I've seen some people only use symbols, they make all GREEN text like in the screens shot, and never go back and put anything in the YELLOW colored text area which is the description. In RS500 your limited to characters in your symbols, so people do some crazy ways of short hand, I do the same, but my short hand might not be the same as everyone else’s short hand so I tried to standardize my short hand when naming symbols by looking at two character short hand based on the NFPA 79. Now what I am trying to say older programmers...they never seemed to use symbols, they just fill in the description area only, the YELLOW colored text. I say this "objectively", because all the ones I've ever worked with, this is true. So am I stereo typing older programmers? You bet I am, because I have NEVER met one that does it any different. I think both symbol and description are important. Maybe RS5000 changes the whole symbol/description relationship that I don't understand. This is primarily because I have spoken out of turn in reference that I have never used RS5000. Hope that clarifies my direction and fore thought.

[Snerkel 0]

As far as I am concerned it is all about structure, the Logix 500 is already structured to a certain extent by the file arrangement. to get the best out of symbols you need to be very structured else it becomes hard work for the engineer following you. That said most of our software uses tags (symbols), often based on client asset tags, the asset tag for a valve for instance makes finding it in a few hundred valves fairly easy, again the tag (symbol) structure needs to be well defined. The descriptive tag starts to lose meaning when you have loads of tanks with loads of valves for instance, to keep the meaning in the tag you are talking a long, long tag. The more complex the tag the harder it is to remember, or to type quickly. The B3:0/0 type adressing in the SLC is easy once you get used to it, and if correctly structured makes symbols fairly obsolite, good descriptions are far more important, you can be in the right file quickly then scroll quickly through the bits/words you know are likely to contain what you are looking for. With Logix 5000 tag structure becomes very important for any reasonable sized job, especially when plant modules can be similar, structured tags usually mean only having to change a small part of the tag to re-use a similar function in another piece of plant. Also tags that cover one piece of plant should be of similar structure, suppose you have a conveyor then something like CV1_PB_Start will be easily scaled compared to Start_Conveyor_1 Let me take that one step further you now have a proximity switch on conveyor 1, the way I would name this is CV1_PX_Piece_Detected Now we add another conveyor similar to the first so we can now use tags CV2_PB_Start CV2_PX_Piece_Detected All the tags are structured, copy and paste the ladder for the new conveyor, change the 1 to 2 and you have a tagged, structured bit of code ready to operate conveyor 2 On very large jobs with Logix 5000 using data types may enforce a slightly different structure that begins to resemble the file structure of the SLC. Tags may begin to look like CV2.Inputs[1].0 the description then becomes very important as the tag alone doesn't give enough info. Really the tag structure can not always be set in stone, a small job with a couple of hundred IO probably can have more descriptive tags, larger projects may well need to structure the tags so good descriptions (and software backups to preserve the descriptions) are a must. Bottom line tag structure matters and may need adapting according to project size. Descriptions and rung comments should be informative, comments describing the operation of a few rungs of code can be invaluable. Software backups need to be paramount to preserve the descriptions and comments.

[jstolaruk 9]

lol, I can tell you guys have never had to program, debug, and "document" an entire job with a PLC2 and finger stubbing T3 terminal. At one time that was state of the art, and as recently 15 years ago, was still used in new equipment. Symbols? Addresss descriptors? The only thing we had was what was on the prints. So the memory addresses became easily remembered because of constant use. Thank god those days are behind me. Anything to make the logic more readable is helpfull. Edited 3 Nov 2005 by jstolaruk

[Snerkel 0]

It is frightning going back to a PLC program you originally wrote using the DOS programming package (and was proud of at the time). Boy does it look bad and unstructured when you open it in RSlogix some 10 or more years later, but it was amazing what you achieved with minimal documentation and remembering which bits/words did what. I cut my teeth on the Cuttler Hammer / Toshiba PLCs a long long time ago using the handheld "Beep-beep" box as we new it. Also backing up programs to memory cards so you could re-use it.

[Guest Guest]

You are wrong...

[jstolaruk 9]

I was just reminded of the cassette tape player we used to backup and restore programs. Its was as big as a briefcase and wasn't very reliable. Edited 3 Nov 2005 by jstolaruk

[TimWilborne 108]

My first "high tech" job was running an old Union Carbide burning table. It still had an 8" disk and the punch tape. Hated not having a backspace button on the punch typewriter Has anyone ever even seen an 8" disk. I hardly remember the 5-1/4" disk.

[jstolaruk 9]

Radio Shack came out with some personal computers back in the late 70s (TRS-80) and the Model II version had two 8" floppy drives (expansion). I used it to write NC programs and then sent it via the serial port to a teletype for punching tape. It was deemed a business computer. $3500 with one drive. Edited 4 Nov 2005 by jstolaruk

[Snerkel 0]

I think us oldies (ish) are very misunderstood by those young wet behind the engineers. When they get a bit of experience with real plant not piddly little machines, and have modified more programs written by others than had hot dinners, then maybe they can start judging us. I try to write my software in a way that is easy to understand, and is very well documented, but getting software without annotation is part of the challenge of modifying existing kit... bring it on. ps I think this thread is getting a little off topic but is very interesting all the same Edited 4 Nov 2005 by Snerkel

[TimWilborne 108]

Atleast it had a nice size monitor. Ours had a 4" monitor and you could only edit one line at a time. And you could only scroll down through the program. On a long program you better better not go past the line you were trying to edit or you had to start over Seems simple now but I was very proud of myself when I managed to hook a computer though then UCNCs serial port. Of course here I am talking about it like it was ancient but I think it was built in 1982 and I think I ran it in 1995. Amazing how much things have changed. There were only a few CADCAM packages then and only the big guys could afford them. Back then I could do trig in my head, now I have a hard time adding without a calculator

[TimWilborne 108]

I do know of programmers that admit they do this. I even know of programmers that do things as unethical as putting timers in machines to give them quirks and even shut them down after a period of time or they have to be called back in for maintainence work. I called on one company after they kicked a guy out for doing this and I could not believe the intentional flaws that had been put in the programs. But it did take them a few years to catch on and he made good money off of service calls to reset a timer

[PLCMaster 0]

Siemens S7 OB80 or time of day interrupt OB's come to mind and unless you truly understand Siemens , you'd be hard pressed finding these faults , as you can disable the error message in the buffers.

[Gerry 13]

How about a PLC-3 with over 5000 I/O programmed, de-bugged, and commissioned with a "finger-stubbing" T4? (while fighting memory module failures and firmware bugs)