advertisement
from the IO Address usage department...
AB SLC 500 Programming
PLCs and related questions. topic
Posted by Steve Murphy on 30 October, 2002 - 11:37 am
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!


Posted by Guest on 30 October, 2002 - 3:13 pm
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.


Posted by Ken Roach on 30 October, 2002 - 3:13 pm
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.


Posted by Anonymous on 30 October, 2002 - 5:12 pm
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.


Posted by Jon on 30 October, 2002 - 5:13 pm
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.


Posted by Robert Chipriano on 31 October, 2002 - 11:42 am
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.


Posted by JGrumby on 31 October, 2002 - 11:42 am
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.


Posted by Michael R. Batchelor on 1 November, 2002 - 12:12 pm
The biggest danger is that you'll stop scanning a ladder and leave an output turned on in a funky state.

--
Michael R. Batchelor - Industrial Informatics, Inc.
Contribute to society: http://www.distributed.net/ogr/


Posted by Bob Peterson on 1 November, 2002 - 12:16 pm
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


Posted by Joe Jansen on 1 November, 2002 - 2:09 pm
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


Posted by Trevor Ousey on 1 November, 2002 - 5:06 pm
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.

Cheers,
Trevor.

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
The world is coming to an end. Please log off.
Advertise here
advertisements
Servo, stepping motor control, analog & web HMI in one system!
Control.com is the largest Automation community on the web. Learn how to advertise here now...
View free setup and multi-vendor EtherCAT demo videos online
Servo, steppers, analog, digital & web HMI - Fully Integrated!
164-page eBook free download - EtherCAT Applications Guide
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive