ControlLogix Learning Curve?

peterjung

Member
Join Date
May 2011
Location
Busan
Posts
7
Hi all

I am new to this forum so please be gentle. I have done some searches through the forums and I can find a lot of discussions on SLC/PLC5 V ControlLogix. However, I can't quite find something to address my particular question. So I would be grateful if someone can point me in the right direction here.

OK, so here is my situation:

I have several years experience in programming with PLC5 and SLC. However, I have been away doing other things for the last few years and not really had much exposure to PLC stuff. Now I find myself with the possibility of getting back into the PLC world, however in the meantime AB have ControlLogix...

I have recently saw some examples of the ControlLogix programmes and I have to admit the whole addressing issues has me really confused?? Right now my brain only thinks of bits and bytes and logical memory addresses...you know N100:27.1 is very clear to me! So the question is...

What is the quickest way to get a full understanding of the new addressing system? Can anyone recommend a good resource, book or other that can get me easily up to speed.

As I said, I can find lots of posts talking about the "learning curve" when moving to using ControlLogix...but not much on how to actually tackle this curve....

Apologies in advance as I suspect that this topic may have been done to death on here.....
 
In Rslogix 5000 you have tags. Tags are nothing but bits or bytes but they have a text name so it becomes easy to remember. So instead of remembering N7:20/1 you can remember Output_on (just an example)
 
In Rslogix 5000 you have tags. Tags are nothing but bits or bytes but they have a text name so it becomes easy to remember. So instead of remembering N7:20/1 you can remember Output_on (just an example)

That much I understand, but the implementation on first look seem very confusing? Perhaps it is just the change....

How do I know the data type (bit integer etc.) for example if there is only just a name?

If I have a 16 bit work called Stauts for example how would I address any particular indivual bit of that word?

Is this explained in detail in any of the manuals anywhere?
 
Hi.
I assume the 16 bit word (an int in AB speak)is called status.
Therefore if you want to address a bit of the word then it is Status.0 or Status.1 etc
When you need a new address you create it as the data type required.
Try to create 32 bit words (dints in AB speak) instead of 16 bit words (ints)as the processor is a 32 bit and everything works faster with 32 bit data.
There is a hell of a lot more to learn but this will get you started.
Regards Alan Case
 
In the most basic of terms, the tag based programming forces you to program symbolically. Please don't fall into the bad habit of naming your tags in the older software.

Everytime I see a Logix platform system with all the tags configured as a PLC or SLC file based system, I re-write it or walk away.
 
When I transitioned a number of years ago I quickly came to this conclusion: Descriptive tag names are good but making the names too long (say by using extinsive _ charachters) can quickly get out of hand.

I've seen a number of people use prefixes to describe tags (int, bol, etc) although I don't think this is necessary as the programming software enforces types quite nicely. I do, however, use UDT (user defined type) when naming them.

I've seen well written code and some real horrible stuff. Totally up to the programmer. But with any non OPP langueage, stuctured programming techniques work the best.
 
I would suggest that you need to start out with a bit more of a plan with Logix5000. There are no predefined structures of data tables. This can be a very good thing, or can just mean a bit of extra planning.

Develop a naming strategy that is concise and flexible for your tags. If you are going to need indirection (especially of bits/booleans) be sure to research or test how the instructions you will need to use will function with boolean arrays versus arrays of DINTs for example. Get a primer on UDTs, and tag aliasing. Learn how to upgrade firmware in CPUs and comms modules. Visit this forum with questions.

I still prefer the editor in RSLogix5/500 since you can do almost everything without touching the mouse, whereas Logix5000 forces you to click more, but that is my only gripe, and it's a tiny one in the big picture.

Definitely learn it(Logix5000)...The logix PACs are superior in almost every regard.
 
Right now my brain only thinks of bits and bytes and logical memory addresses...you know N100:27.1

No reason that you couldn't name a Dint tag N100_27, then your bits within would fill in as N100_27.0, .1, .2, etc. After a while you would say to yourself that it would be nice just to name this tag 'piece_count' or something descriptive.
 
In the most basic of terms, the tag based programming forces you to program symbolically. Please don't fall into the bad habit of naming your tags in the older software.

Everytime I see a Logix platform system with all the tags configured as a PLC or SLC file based system, I re-write it or walk away.


No reason that you couldn't name a Dint tag N100_27, then your bits within would fill in as N100_27.0, .1, .2, etc. After a while you would say to yourself that it would be nice just to name this tag 'piece_count' or something descriptive.


We've got a couple machines in our plant that have their ControLogix programs tagged like "old-style" addressing.
One of my co-workers really likes this style but he's used to 5/500 and still has a hard time with 5000. I don't see the point in having the tags defined this way since they also need good descriptions to guide you through the logic.

Our regular integrator uses object-oriented tags so that's how most of our contrologix stuff is tagged. With these tags you really don't need to have that super-detailed description since the tag name itself can describe what it is.


I started out my PLC career learning 5, 500 and 5000 at the same time, so I kinda got hit with learning two platforms that are similar but not similar.
I have some previous experience with C/C++ programming and my habits are to define tags objectively. I think that made it fairly easy for me to undeerstand how the tag system works in 5000.
It actually took me longer to get my brain wrapped around the "old" Bxxx, Nxxx, addressing method.
 
Last edited:
Thanks to everyone who posted on this subject..very useful and educative!

I just got back from an extended business trip so I was unable to reply until now.

Thanks again to everyone...I'll bite the bullet and get up to speed on the new way...(y)
 
I think there are a few lessons to be learned when learning the tag structure of the Logix 5000 Platform...

1. Understanding the DINT data type optimization of the Logix series. Understand this and you'll understand how to efficiently use memory. If you start to read the manual you will come across this.

2. Standardize your tag structure, as many have already said tags can get sloppy and inconsistent really quickly. Plan out a "standard" structure.

3. As you advance your knowledge, begin to understand user-defined tags, and begin to implement them.

4. Base Tags and Alias tags, how they are related, and how they can make your programs more efficient. Probably tie in program tags versus controller tags as well.

5. Tags and communications with the outside world...learn how RSLinx handles comms with a controllogix, understand what "online" program changes you do could affect the efficiency in which RSLinx or other OPC servers communicate with the system.

There are some topics to begin to study, it has taken me a couple of years to gain this knowledge, so don't feel like you need to understand all of this immediately, the point is to know that you need to get a "deeper" understanding of the Logix platform to really become good at writing code for it.


Other topics:
Tasks, Add-On Instructions, Phase Manager, Firmware, Import/Export tools......
 
You can also get "brainy" with this logic too. My current PLC (done by OTHERS) is like that. Instead of the logic being "out there" and easy to follow, there's an unreal amount of setting up subroutines for every. single. item. in. the. PLC.

For instance, my motors are named "Motor[1]", etc. This is all nice, but there's a big learning curve by having to remember or trace out everything, because nothing is done with consistency. There's no major speed advantage by using subroutines either; straight logic is easier to follow and diagnose. I have to use Wonderware's addressing scheme to find things in the PLC sometimes!

Lots and lots of JSRs in the "MAIN" section can be your friend. This program has "Motors", "Solenoids", and "Pilots" as program sections instead of "Oil Pumps", "Fire System", "Gas Compressors". I don't see it being changed anytime soon, but PLEASE try to organize your system for the next guy as you plan it.

The next guy could be me, and I'm easily confused! :D
 
You can also get "brainy" with this logic too. My current PLC (done by OTHERS) is like that. Instead of the logic being "out there" and easy to follow, there's an unreal amount of setting up subroutines for every. single. item. in. the. PLC.

For instance, my motors are named "Motor[1]", etc. This is all nice, but there's a big learning curve by having to remember or trace out everything, because nothing is done with consistency. There's no major speed advantage by using subroutines either; straight logic is easier to follow and diagnose. I have to use Wonderware's addressing scheme to find things in the PLC sometimes!

Lots and lots of JSRs in the "MAIN" section can be your friend. This program has "Motors", "Solenoids", and "Pilots" as program sections instead of "Oil Pumps", "Fire System", "Gas Compressors". I don't see it being changed anytime soon, but PLEASE try to organize your system for the next guy as you plan it.

The next guy could be me, and I'm easily confused! :D

Ehem...you wouldn't like my code ;)

This is a struggle for any programmer, on one hand you need to standardize and generalize code so you can be efficient and cheaper in order to win the bid and get the work done in the allotted time. On the other hand you want the customer to take ownership. Unfortunately cost is the bottom line which usually means the "kiss" method just isn't cost-effective.

As much as I would like to write code for the lehman, in this day and age it's extremely hard to do. Loops, indirect addressing, standard sub-routines, standard tags and AOI's allow me to build 80% of my code in a matter of hours(this applies to any system, the time may vary due system size). The remaining 20% is process related, and takes longer as every system is different. I don't see how I could achieve this type of efficiency if I didn't standardize. After all, "Motors", "Solenoids", "pilots" are universal to every system. "Oil Pumps", "Fire System", "Gas Compressors" are not.

I am confused by the "straight logic" remark, are you saying that a single sub-routine of 1000 rungs of logic is easier to follow than 10 sub-routines of 100 rungs each? I certainly don't agree with that, but then it's personal preference at that point.

But, in your example simply creating alias tags might clear up a lot of the confusion you are experiencing. In the end, everyone is different, some have better methods than others and some have different perspectives than others.
 
Ehem...you wouldn't like my code ;)

This is a struggle for any programmer, on one hand you need to standardize and generalize code so you can be efficient and cheaper in order to win the bid and get the work done in the allotted time. On the other hand you want the customer to take ownership. Unfortunately cost is the bottom line which usually means the "kiss" method just isn't cost-effective.

As much as I would like to write code for the lehman, in this day and age it's extremely hard to do. Loops, indirect addressing, standard sub-routines, standard tags and AOI's allow me to build 80% of my code in a matter of hours(this applies to any system, the time may vary due system size). The remaining 20% is process related, and takes longer as every system is different. I don't see how I could achieve this type of efficiency if I didn't standardize. After all, "Motors", "Solenoids", "pilots" are universal to every system. "Oil Pumps", "Fire System", "Gas Compressors" are not.

I am confused by the "straight logic" remark, are you saying that a single sub-routine of 1000 rungs of logic is easier to follow than 10 sub-routines of 100 rungs each? I certainly don't agree with that, but then it's personal preference at that point.

But, in your example simply creating alias tags might clear up a lot of the confusion you are experiencing. In the end, everyone is different, some have better methods than others and some have different perspectives than others.

I couldn't agree with you more, unfortunitly its a dog eat dog world, we are only given so much time to do what needs to get done. Only thing I would add is if you plan up front you can optimize the code with user defined tags and add on instructions. these will definitly be your friend in the long run.
 

Similar Topics

Hello Everyone, I am starting a new job in a couple of weeks and all the PLC's are ControlLogix Controllers. I have not really used Allen Bradley...
Replies
7
Views
5,521
Hi everyone i have a customer, who wants to show an alarm on the machine, if the I/O forces are enabled and set, on at ControlLogix L81E with...
Replies
3
Views
138
Does anyone know of a way to detect if someone is online with the controller in ControlLogix (from logic) I'm thinking that maybe there is a CIP...
Replies
7
Views
291
I've never paid attention to this, is this normal?
Replies
13
Views
418
Hi. I need suggestions. I want accumulate operating hours from a simple XIC condition, so I'm thinking a RTO with a 60000 or 3 600 000 preset, 1...
Replies
7
Views
225
Back
Top Bottom