![]() The solution is to use a separate rung for each input: a contact for the “real” input and a coil for the “internal” input that you use in your program. Quite painful when you’re trying to fix a machine. You still have to figure out that you’re looking at the 5th bit in the UDT, and then you know it corresponds to output 4 in the I/O card. How would you go about finding that input? You can easily right click and do a cross reference, but that only brings you to the copy instruction. You have to find the input bit that corresponds to the UDT tag bit, and force that. There are two problems with this: first, UDTs can’t be edited without downloading the processor, so if you change an input you have to stop the machine, and second, if you’re using the UDT tag in your program, you can’t force those bits directly. Contact and Coilįaced with the problem above, what I see a lot of programmers do is define a UDT for each input card, and then use a copy instruction to move the hardware input state into the UDT tag. Then you can forget about synchronous/asynchronous and go about your business. With RSLogix 5000, I suggest solving it by creating a MapInputs routine that “scans” your inputs into temporary coils at the beginning of your program. ![]() They would copy the state of the input to an internal coil if they had to use it in more than one rung. In the days of the PLC/3, I understand programmers used to make sure they didn’t use any input more than once. Rare, but possible, and it leads to bugs that are intermittent and very hard to find, especially in logic that deals with critical timing, like data collection or communication logic. Both Output 1 and Output 2 could be on during the same scan, or off during the same scan if Input 1 changes state between the time that it solves the first rung and it solves the second rung. However, with asynchronous I/O, our assumptions are wrong. …and you could be certain that Output 1 and Output 2 would never be on at the same time. That meant you could write things like this: ![]() ![]() ![]() The important thing to realize is that the state of an input could never change during the logic solve. Then it “scanned” the outputs by copying the output coils to the actual hardware outputs. In a SLC 500, the PLC “scanned” the inputs by reading the state of the hardware and storing them in memory. In the PLC/3 world, I/O was asynchronous, and in a move that surprised many programmers, the ControlLogix/CompactLogix platform uses asynchronous I/O as well. If you come from the SLC 500 or PLC/5 world, you’ll be used to synchronous I/O, and that made your life a bit easier. It’s important that you understand the difference between synchronous and asynchronous I/O in PLCs. This is part of an RSLogix 5000 Tutorial. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |