inputs controlling outputs

[yellowledbetter 0]

I think i remember reading somewhere that it is not a best practice to have an input directly control an output. For example a pushbutton turns on input I1:1 and that turns on an output O1:1 it is better to have the input set a bit, and then in another rung have that bit, when true set another bit, and that second bit is mapped to an output. if so, what is the advantage of doing this?

[RussB 22]

I think it depends on the controller, some will not allow for an Input to be forced from the programmer. So by using an interposing internal relay the programmer has more control from the keyboard when commissioning. I know of no other advantage.

[BobB 58]

Argh -0 inputs controlling outputs - the middle is the most important to my mind.

[yellowledbetter 0]

please explain

[OkiePC 14]

What you describe is sometimes called Mapping the I/O. I generally prefer to use "mapped" inputs and outputs. a) I don't need the I/O drawings to create a solid control program...I can fill in the I/O address details later... b) I can easily swap the device type in one spot in the code (change a photocell from light operate to dark operate for example). c) asynchronous I/O updates become a non-issue if you sync them yourself. On the downside, there will be more logic, approximately one rung per input and one rung per output. I believe what Bob is saying is that mapped or not, it is the quality of the logic in the middle that matters most... In almost all cases, mapping is purely for convenience and structure, and offers no logical improvement to the machine behavior. More discussion: http://www.plctalk.net/qanda/showthread.php?t=65861

[BobB 58]

Yes - inputs are inputs and outputs are outputs - it is the stuff in the middle that makes if work properly or not. Cause and result?

[yellowledbetter 0]

thanks for the input guys!! Now, i see the advantages of doing this. Is there a preferred, or easy way to get this done. Edited 24 Mar 2013 by yellowledbetter

[kaiser_will 65]

Inputs tied directly to outputs often can lead to having to deal with problems such as unplanned operation, such as input bouncing (i.e., proximity sensor toggling state). A well thought out program standard to debounce inputs and generate all conceivable alarms is the direction most firms have been heading, instead of creating a new fault every time a new situation occurs.