Learn to program RSLogix 5000

Produced Consumed Tags

Logix 5000 allows data to be transferred between controllers utilizing a Producer – Consumer model. The data is transferred over Ethernet/IP, ControlNet or the backplane. It’s really fairly simple; PLC-B needs data from PLC-A, so PLC-A sends the data to PLC-B. PLC-A is the producer and PLC-B is the consumer.

As you have probably guessed PLC-A will need to have Produced tags configured, while PLC-B will need Consumed tags configured. Creating Produced and Consumed tags is not much different than creating a “Base Tag” or “Alias Tag” with a few exceptions and rules.

A Produced/Consumed tag must be a DINT, REAL, or a Structure and be controller scoped. If a Structure is used it may contain a BOOL, SINT, or INT You can find out more about logical Data Types here. I was also able to use a STRING data type.  Keep the produced and consumed tags under 500 bytes. If more than one tag is to be used group the tags together in a structure to limit the amount of connections the processor will use. That isn’t so bad right, wait there’s more. The Consumer PLC must have the Producer PLC in its I/O Configuration. You must be offline to create Produced/Consumed tags, sorry you can’t do it online. And as a final note leave the RPI settings at the default. If you feel you have to change the RPI and other “advanced” configurations visit Allen Bradley’s website and read some data sheets.

{ 0 comments }

Set the project path in Logix 5000

If you are planning on going online with a processor more than once it’s an excellent practice to use the “set the project path” button in the who’s active window. I bring this up because not only will it save you time, more importantly it decreases your chances of making a mistake especially when downloading. In more than one case I have been in a production plant that has several very similar machines which makes it very easy to inadvertently download to the wrong machine. You can also very easily upload from the wrong machine. The point is set the project path once and don’t worry about it again.

{ 0 comments }

Do you use the RSLogix 5000 Bookmark?

B is for Bodacious Bookmark! If you don’t see it you will need to enable it. Open the view menu, toolbars…, and put a checkmark by the Bookmark Toolbar. This is a super handy tool to use when you’re jumping from routine to routine, or whatever. In a nutshell you can drop a bookmark on a rung of interest. Then as you’re cross referencing tags and hunting down logic you can simply use the handy next, back, or go to bookmark buttons for quick easy navigation back to where you started. You will thank me later for this one. Check out the video tutorial

{ 0 comments }

1 – Programming Standards – Tag names, structures, comments, routines, programs, tasks; all should be implemented utilizing programming standards.  If you want to write readable, repeatable, portable code you will need to follow some kind of a programming standard. A successful engineer will follow programming standards relevant to the project they are working on. This is important so I will say it again, standards relevant to the project they are working on. Programming standards can, and do change from project to project. Sometimes a contract dictates the programming standards. Other times it may be the production or processing plant that dictates the programming standards. If you’re in the business long enough you will hear the “know it all engineer” that tells you there is only one programming standard and it is his. We all know one of these guys. The important thing here is to develop a habit of using standards.

2 – Programming consistency – Consistency follows right along with programming standards. Be consistent with tag names, comments, routine placement, and program instruction usage. Consistency is the icing on the cake while programming standards is the cake. Write code that is consistent. A great example is comments. Use them objectively not subjectively. As programmers we tend to comment heavily on code we perceive as complicated, or poorly written. While on the other hand code we perceive as simple tends to go uncommented, I am guilty of this one. The latter is subjective commenting and is inconsistent. When writing rung comments remember this: “What may be complex to me may be a breeze to others, and what may be simple to me may be complex to others.”

3 – Keep a Cool Head – Don’t fool yourself, being a controls engineering career is quite stressful at times. It’s easy to lose your cool and point fingers and throw blame in every direction. The project manager has set unrealistic dates. The electrician wired it wrong; I can’t help it if he can’t read schematics. There are thousands more where these came from. The point is something bad is going to happen on every project. A professional keeps his cool and offers solutions to problems not create them.

4 – Ask for help as well as offer help – If there is one thing consistent with successful engineers is they are not scared to ask for help when they need it. Let’s be honest everyone needs help from time to time. Be willing to help others, don’t make the mistake of hoarding knowledge. Keeping information from others does not give you job security, it actually does the opposite. The more you share your knowledge the more successful you will become. It’s one of the laws of the universe. Share your knowledge freely and the doors of opportunity will open.

5 – Don’t Be Afraid To Get Your Hands Dirty – I mean it, really! Don’t be that guy that sits at his desk and says stuff like “well the code didn’t change what did you do to it?” Get up, go to the process and find out what the problem is. Help the electricians, maintenance and operators. Walk a mile in their shoes. Make a habit out of engaging in the entire process. There is no faster way to success. You will be amazed at that insight you will gain.

6 – KISS Keep It Simple Stupid – Successful programmers write code that is as simple as they can possibly make it. This is a habit. Successful programmers will not take some fancy new instruction they learned and force it to solve a problem. They take their knowledge of instructions and apply the instruction that best solves the problem. In other words they don’t ask: “How do I use x instruction to make y happen?” rather they ask “What instruction should I use to make y happen?” Make a habit of objectively examining the work that is to be done, then make a decision about how it will be done.

{ 0 comments }