AB SLC 500 Programming


Thread Starter

Steve Murphy

Allen Bradley slc 5/04 processor & RSLogix 500 software. It's an unwritten rule that you can't use the same input and output addresses across multiple ladder files. Instead you are supposed to map your IO to bit addresses in the first ladder file, then use the bit addresses. I know strange things happen if you spread IO across files (I've done it!!!) but can anyone explain exactly why??? I'm sure it's something to do with program scans.
Any feedback greatly appreciated!
I think this is not right. I used same I/O addresses in several ladder files and I have never faced this problem. I have done this on several projects and it was never a issue.
Of course you can use Input data in any ladder logic file in the SLC-500 controllers. Nothing "strange" happens if you reference Bit 0 in Ladder File 2 and Bit 1 in Ladder File 3.

It's bad programming practice to use the *same* output bits or words in more than one place, but only because it can become complex to determine which output instruction takes precedence.

The SLC is very deterministic about it's I/O data; the housekeeping routine at the beginning of each scan reads Input data and writes Output data from the previous program scan. There's no need to copy data into holding registers.

ControlLogix systems, on the other hand, use change-of-state I/O updates so you can't be certain that data conditions at the time of one rung executions will be exactly the same as data conditions at the next. I've seen many users provide buffer tags to make a ControlLogix have consistent input data all through the program scan like the SLC does.
You are misinformed. There is nothing wrong with this approach. PLC3's and ControlLogix have problems because I/O is not updated before or after scan but during the scan. SLC's updated Inputs and outputs post/pre scanning the program.
It is generally considered bad practice. You can if you like but say a card is moved to a different slot or something else is wired to that point. Instead of scouring your whole program finding every little Input/output bit, all you have to change is the mapping. Makes life and trouble shooting much simplier if it comes to it. Modifications and expansion is simplier too.

Robert Chipriano

It is not a matter of the program not performing correctly. Once the processor does its housekeeping and updates the input image table (files), the processor does not care if the rung logic in the program is completed by a "real world" I/O bit or a binary (B file) bit. It is a matter of maintenance once the machinery is put into service. If you map the input to binary bits in only one place, it makes it much easier if you have to move an input to a different input card terminal. Such a situation would arise if you had an input terminal on a card that went bad, or for some other reason, the field wiring had to be changed or rearranged. If you have the input I:xx.x driving a binary bit in only one place, and then use the binary bit throughout the program, you have only one program rung to change if the field wiring changes. If you use the input address directly throughout the program, you then have to do a search and replace for that particular input address for each place that it appears in the entire program.
There is nothing keeping you from using an input bit as many times as you want in as many files as you want. The same is true of an output bit, but the physical output will be updated to the status of the last scanned output instruction. Of course you can structure your program to control which subroutine was scanned last, but it is far easier to just put only one reference to the output in a routine that is constantly scanned and put selective logic in front of it.

Bob Peterson

I am not all that sure what you are asking. Some people like to use buffer files for I/O because on some projects I/O gets moved around a lot, and its easier to change it in one place rather than multiple places. Others buffer real I/O to simplify debugging.

With RSLogix500 its pretty easy to do a global replace on an I/O point, so I see no reason to do it for that reason.

As for debugging, this can be a useful tool, since the SLC architecture will not allow you to run a program in a different size rack than what its configured for. This maybe why your company has this "unwritten" rule, but it is by no means a universal unwritten rule.

I see no reason not to spread I/O out across mutiple files. Inputs and outputs are still updated between scans so its really not all that important.

Bob Peterson
I have been programming AB processors for over 10 years, this rule has never been true for any of the SLC processor line. Since the introduction
of 5/04, it has not been true for that unit either..

Obviously, using the same output address for a coil will cause seemingly strange things, but they are predictable. If ladder file 2 has an output coil labelled O:1/0, and it is energized, this will be on INTERNALLY ONLY through the rest of the scan. If it is never referenced again, the output will be turned on between scans.

If, however ladder file 4 has an output coil also labelled O:1/0, and it is not energized, then it will be turned off internally. If this is the
last reference, then the output will stay off.

Not that if you have a contact ( --| |-- ) that looks at O:1/0 in ladder file 3, using the same example above, and another in ladder file 7, the
one in file 3 will see the output as being on, and the contact in file 7 will see it as off. And off it will remain, since that is the last
commanded state. The contact in ladder file 2 sees it on, because it was turned on in file 2. This is all predictable.

There is no unusual/unexpected behavior using inputs. You can look at them whenever/wherever you want.

actually, your description of mapping the I/O to internals means that the outputs are not updated until the scan after the logic turns them on. This
is because if you turn on B3:0/0 in ladder file 5, and then B3:0/0 turns on O:1/0 in ladder file 2 on THE NEXT SCAN, it will not come on until the
end of the second scan. This could cause some latency problems, depending on the application.

--Joe Jansen

Trevor Ousey

Use only one instance of an OTE is right, unless you are being 'tricky' and making a difficult for others to follow, but inputs can be multiples
all through the program. The SLC does an IO update at the end, so the last OTE scanned will set its state. This is the same with PLC5's,
unless you use immediate IO update instructions. What you state has some validity in a controllogix as the IO can be updates asynchronously (I think), so it is not uncommon to have inputs mapped.