ControlLogix I/O addressing

R

Thread Starter

Randy DeMars

My company is about to build its first machines using the Allen Bradley ControlLogix processor. I am wondering what the rest of the world is using
for I/O addresses.

We currently use SLC500 and PLC5 processors on the machines that are spec'ed with Allen Bradley PLCs. On the electrical schematics, we label the I/O point and the wire to the I/O device with the PLC address for that point.
For example, a wire may have been labeled I:021/01 if it were connected to an input point in rack 2, group 1, second point. This makes sense, and I am suspect that it is similar to what the most companies are doing.

ControlLogix controllers, on the other hand, do not use this type of I/O address. You are free to refer to the I/O point with any label that you
desire. From what I understand, there is an I/O address of the form Location:Slot:Type.MemberName.SubMemberName.Bit assigned to each I/O point by the configuration process, but using this as the label may cause problems when there are more than one processor in the system (For example:
LOCAL:1:I.Data.0 can describe more than one point if you have 2 processors in two different racks in the same PLC system.

I am sure that some standard will emerge for this, if it has not already. I would appreciate any information that the list can provide.

Thanks
Randy DeMars
 
W

Wally Temple

Randy,
We are using the form ChassisSlotBit for discrete I/O. This provides for a six digit wire number and terminal label for our use. I think something similar would work for analog. For chassis numbers we are using the controlnet address of the primary network card in that chassis. A simple numbering scheme would work as well.

That is the plan, for now. This is also our first system using the platform. More later, if things change
 
G

George Robertson

For drawings, we just use rack/slot/point and do business as usual with Controllogix. Anyone interested in the address can find out from the alias tables in the software.

Obviously, it would be nice if the programmers would use symbolic names similar to the loop tagname, which would also help in troubleshooting later.

Hope that helps!

[email protected]
George G. Robertson, P.E.
Manager of Engineering
Saulsbury Engineering and Construction
 
T

Trevor Ousey

We are about to do the same thing, and my idea is to allocate a number for each rack, a number for each slot and an I/O point number. Hence we will end up with a number as 01-09-30 which will be rack 1, slot 9 and bit 30. The relationship to the PLC logic will require a drawing cross reference, or you could tie this into the alias tagname. The ControlLogix does make it a different ballgame, but it sure is impressive over the PLC and SLC series. :) I found a lot of similarity to the Gidding & Lewis PIC900, but it had an easier online I/O addressing table, sort of.

Regards,
Trevor Ousey.
 
J
Actually, the wire numbering scheme that I have seen to be most prevelant during 7 years of robotics integration work is a 5 digit wire number, where the first 2 digits are the last 2 numbers of the electrical print (page number), the second 2 digits are the line number on the page, and the optional 5th digit is an A, B, C, etc. if there are more than one wire on the line (for example, if the first line on page 1 has a wire from power to a start button, to a stop
button, to a coil, to neutral, you would have 24V, start button, 0101A, stop button, 0101B, coil, 0V in that order.

Tags in the PLC then refer to device number. In the above example, the start button would be PB0101A, the stop button would be PB0101B, and the coil would be CR0101.

By using the electrical prints as the basis for your numbering instead of I/O addressing, you eliminate the problems of multiple processors in the same system. Note that even on the old method
you describe, if you have 2 processors in the same system, which one does wire number O:2/5 go to?

--Joe Jansen
 
P
My last job was very similar to this, except that we did 4 digit numbers that were the line numbers from the electrical prints. No page reference was needed since the line numbers were deliberately unique. The company had been doing that for years; since it was an OEM, I took it a step further and we blocked out specific ranges for specific I/O. For example, a wire numbered from 1000 to 1099 was a thermocouple; 1300 to 1499 was a discreet input; etc. For TCs and analog signals, plus/minus signs were added for signal and common ie, 1010+ and 1010-. We did exactly the same with A, B, C etc for wires that were on the same line in the print package. I should note that for the loop drawings, we had ACAD layouts
that approximately matched module I/O counts so that we didn't "waste" numbers in the loop drawings. Thus, an 8 channal analog input module might be laid out with line numbers 1200 to 1209, with the spacing set up for the 8 channels on
the module. A 16 point input module would be 1300 to 1319, again with spacing matched to the module so that line numbers and the "wire" matched exactly so that the electrician had no doubt as to what line number was what input. We also
labeled each wire in the print with the controller I/O number, but that was for the programmer not the electrician. It worked very well... I am planning to do something similar with my present job <g>. What worked out especially well was blocking out ranges. That made maintenance a lot easier since you could tell at terminal strips and J-boxes just what you had, and it made setting up the prints easier because several people could work on the package (or one person could work on different parts of the package) without worrying about the numbers being used elsewhere.

Paul T
 
M

Michel A. Levesque, ing.

Hi all,
There are two aspects here:
Wire numbering and Symbolic Addressing

There are many many schemes for wire numbering the most prevalent being:
Rack#/Card#/Point# (ex. 01/05/12)

The problem with using this in a CLX (ControlLogix) is that the Rack# is not the most intuitive which card is the primary. So to this end we use the following:
Panel#/Rack#(inside panel)/Card#/Point# (ex. A101/01/05/12)

This allows any electricien/instrumentation persone to quickly locate and the EXACT I/O.

Symbolic addressing is more involved. We use the exact same method to create a base tag:
Panel#/Rack#(inside panel)/Card#/Point# (ex. A101/01/05/12)

But we also add an alias tag which references the base tag. This alias can then be anything you want, typically we use a modified ISA method of tagging loop#/code/suffix (ex. 100TT5A)

The actual ladder (or function block) programming uses only alias tags.

By providing two tags (base and alias) we effectivelly split physical from logical.
This allows the easy reuse of code (change the alias referencing). It also allows the use of structured tags. (ex. motor101 contains
start,stop,jog,run,running,stopped tags in one easy to access structure). Again code reuse is easy and you can generate massive quantities of programmes or tags by using the search and replace
feature.

This is by far the most efficient method of ladder programming I've done. Once a typical
motor code is developped, you can get a new motor control up in less than 10 minutes.

Michel A. Levesque eng., mcp
Directeur Bureau Montreal
AIA Inc.
[email protected]
 
J

James Ingraham

All this is pointless.

Give the point a meaningful name, like "Start Pushbutton". If you want to know where that is, look at the base tag.

Wire numbers, loop numbers, drawing page numbers, etc. should NEVER be part of the name. The description field for the alias tag or for the base tag can have that information. Any scheme you're comfortable with will work. Just don't try to shoe-horn the old I/O scheme into the new one. It diminishes the value of the system.
 
G

Greg Goodman

> Give the point a meaningful name, like "Start Pushbutton". If you
> want to know where that is, look at the base tag.
>
> Wire numbers, loop numbers, drawing page numbers, etc. should
> NEVER be part of the name. The description field for the alias tag
> or for the base tag can have that information. Any scheme you're
> comfortable with will work. Just don't try to shoe-horn the old I/O
> scheme into the new one. It diminishes the value of the system.

[Note: this is a general response about I/O naming conventions, not necessarily applicable to the original question about ControlLogix.]

I agree with you that logical meaningful names make the system more understandable, usable and maintainable. But "meaningful" is a function of your audience, the intended user base.

A new system, without historical baggage, should certainly be built as cleanly and logically as possible. And if you are establishing the
naming convention for your own company, for a system that you are going to operate and maintain, then you can define what's meaningful.

It can be a little different for consultants and integrators. A lot of the systems we build consist of new software controls sitting on top of existing (occasionally ancient) I/O, for operators and techs who have been working in the same control room for years, sometimes decades. They already have a nomenclature for the elements of the system, and we try to make sure they don't have to learn a new one in order to use the system or diagnose problems. So when the tech
on the other end of the radio says "close the #3 relay on hoist 5", I don't want to have to explain that I've renamed the #3 relay to
"set_hoist_brake" and that hoist 5 is now called
"furnace_3_south_hoist".

That said, the description of #3 relay on hoist 5 *is* "Fce 3 South hoist brake". The process IT guys who maintain the software and the database have a reference that is meaningful to them. But the interface software in that system only searches for tags by name, not description, so we make sure the techs in the field can find what
they're looking for, using references that are meaningul to them.

--
Greg Goodman
Chiron Consulting
[email protected] -- http://www.swbell.net/chironsw -- (713)
869-6876
 
Top