Latching Inputs?

[Wild Bill 0]

I ran across a program that was sent to me by someone that was using an input to latch an input. -------[ ]------------[ L ]-------- I:1/0 I:1/1 Why and what would the rationale be behind this????? Has anyone ever seen this being used??? Edited 7 Feb 2007 by Wild Bill

[Guest]

it can be used as a temporary “fix” or troubleshooting tool ... when the first input is ON, the latch will write a 1 into the second switch’s bit/box ... the rest of the program will interpret the status of the second switch as though it is ON ... once the first switch is released (OFF) then the update of the input image table will “unlatch” the second switch by writing a 0 into the bit/box ... basic idea: you’re “hijacking” the status of the second input by “overwriting” its status with the latch ... we cover this in the “boot camp” course ... it really helps the students understand the processor’s scan sequence - even if they NEVER use it ... personally I do NOT recommend it as a programming technique ... it’s just too “weird” for most people’s taste ... it can also be VERY handy to "simulate" the operation of a non-existant hardware switch (for example I:1/1) - by using another address that you DO have available (for example I:1/0) ... Edited 7 Feb 2007 by Ron Beaufort

[semilogical 0]

In the early days of my plc experience I was told that latching real I/O was a very bad thing to do. I know many programmers that will not use latching (OTL) in any program. They will use a line of logic to "latch" something but hesitate to use the instruction. I have used a live processor to debug programs without I/O attached (if the I/O is configured I go to status and inhibit the racks and slots I'm using. When doing so I will create a program file for manipulating bits and overwriting the I/O scan. It would be something like this: XIC B3/0 OTE I:1/1 If I wanted to turn on an input I would toggle the B3/0 bit. You can sequence an operation by creating code to step through a desired program function. The above description only debugs what you can see in the program but has no impact on any equipment until you are fully live. Remember to un-inhibit the real I/O before trouble shooting your project. If the I/O remains inhibited you will never see your outputs function, or your inuts for that matter

[Guest]

Greetings semilogical ... well, I won't argue with that ... but then again ... you might be interested in some of the ideas in this thread ... it points out a few instances where certain types of real I/O might actually REQUIRE a "latching" operation for safety reasons ... it's kind of long - but I think that it's worth reading through ...

[TimWilborne 108]

Why you would look at an input and latch another input I'm not sure, but having ways to latch inputs and outputs in programs is not that uncommon. Other PLC manufacturers don't have an I/O forcing feature so this is a way of writing one into the program

[BobLfoot 301]

Good response Ron - one other possibility is that the original poster found this logic in a Debug Ladder File and needs the second input on in sync with the first. Also noteworthy this "hijack" will not work reliably with the ControlLogix Faily since I/O updates are async to the scan whereas PLC 5 and SLC 500 have a fixed I/O update phase.

[Wild Bill 0]

Thanks folks for the help. I did take a look at the thread and saw some interesting ideas. It just didn't make sense to me to latch an input with the exception as Ron had said, in troubleshooting. However, I am a firm believer that OTL is not to user friendly unless you really know what you are doing, and I dont!!! Thanks again. Wild Bill Edited 8 Feb 2007 by Wild Bill