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!

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.

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.

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.

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 introductionof 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 thelast 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, theone 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 lastcommanded 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. Thisis 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 theend of the second scan. This could cause some latency problems, depending on the application.

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 multiplesall 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.

Users of this site are benefiting from open source technologies,
including Linux,
PHP,
MySQL and
Apache. Be happy.
This page served by Yesod4 in the beautiful
Blackstone Valley of Massachusetts, the home of the American Industrial
Revolution.

FortuneSome men are heterosexual, and some are bisexual, and some men don't think
about sex at all... they become lawyers.
-- Woody Allen

You have clicked on the "?" button for search help. To search the
site, enter your search terms in the box labeled "search the site"
and hit Enter.

Some tips for better search results...

Precede each search term with a "+", as follows:

+Modbus +TCP

Otherwise, any post with either term will match.

Use double quotes around phrases, as follows:

+"Allen Bradley" +ethernet

Otherwise, posts containing these words in separate locations will match.

To exclude a word, precede it with a "-", as follows:

+Modbus -Plus

This will return only posts containing "Modbus" but NOT containing
"Plus".

Note that common words (and, that, etc.) and words shorter than 2 characters
are automatically excluded from searches.

Your subscription request is being
processed.

You must be a Control.com member
to subscribe to threads. Please log in and try again.

If you're not already a member, consider joining. It's free,
and you can customize the content you view, as well as being
able to subscribe to threads and topics, getting new posts
delivered to your email as they appear.

Username

Password

Remember me on this computer

Select the categories for which you would like to
see messages displayed...

Applications

Application Questions and Problems

Automation Business

The Business of Automation and Control

Communications

Communications systems and equipment.

Engineering

Engineering and workplace issues.

HMI

Human-Machine Interface and SCADA.

Information

Information resources, documentation.

Languages

Programming languages.

Motion Control

Motion control, servos, steppers, etc.

Networking

Local and wide area networking in factory automation.

Open Control

Open interfaces, software and hardware

PCs in Automation

Computers in manufacturing; also hardware discussion.

PLCs

PLCs and related questions.

Power Generation

Power generation equipment control.

Process Control

Continuous process industries, DCS questions.

Sensors

Sensor technologies.

Software in Automation

Software, including programming, OS issues, etc.

You must be a Control.com member
to vote on a post. Please log in and try again.

If you're not already a member, consider joining. It's free,
and you can customize the content you view, as well as being
able to subscribe to threads and topics, getting new posts
delivered to your email as they appear.