Siemens failed input tip

Ever had a failed input on a Siemens PLC?

If, say, I0.0 failed and you had a spare input point, say I1.7, you could strap a link between the two then insert a new network at the TOP of OB1:

'I1.7'..............'I0.0'
|-] [------------( )|

this could temporarily get you out of trouble. If for example you were utilising Input Bytes within your program these would not be affected as they would if you changed all I0.0 to I1.7 manually.

So why not use symbols? Then you could change the address that "points" to the symbol used in the program. Then you do not need to change the program logic.

/shudder

Why does even the thought of that scare me?

Then again, it opens up the possibility of writing some really REALLY confusing code... hrm...

Maybe we need an "International Obfuscated PLC Code Contest"....

(edit... Comment on OP's tip... not the followup)

I was curious and tried what you suggested silva.foxx, and it does work. I added a network to examine I1.7 and set I0.0 and tried it in a PLC and it worked. But I do not think I would ever do this. I think it would get too confusing.

seems like a good quick fix, tho. and in my field we have lots of deadlines and quick fixes are the norm.

From what I gather you can add it to the program whilst it's running therefore preventing a stop in the process.

Obviously at a later time the fault will be rectified in the proper manner, but as a very short term "get out of jail" quick-fix it's worth a bash!

Keep as a trump card! Produce it when in deep dung or at a 'stupid-o'clock' call out.

I am not saying use it as an elementary programming technique, at all, but if used; log it and identify it with tags, bells and big, neon flashing lamps!

Has this been fully tested?

If Input I 0.0 Failed ON (TRUE)
will the replacement I 1.7 replace it properly?

In other words who "rules" the I/O or code in OB1?

Just a thought!

An extension to this quick fix is when the limit/proxy switch fails and the only one you have is the opposite sense. The code at the start of OB1 is thus:
an I0.0
= i0.0

This saves you having to change all the logic in the program.....

There is also a caveat that goes with this type of "fix". Sometimes, especially in interrupt routines, the process image can be updated so the current state of the input is used. e.g.
L PIB 0
T IB 0

This will overwrite what OB1 has done.

Concerning bells,neons etc, my programming standard uses a global flag M1.7="INeedFixing". Any temporary fixes use M1.7 in the logic (but coded so it doesn't have any effect). After the panic is over, you (or anyone else) can search for all the M1.7's and then work out fixes when the panic is over.

The idea of using symbolic addressing to ease the way round this problem is a good one. "Pushbutton" should do the same thing in your program, regardless of whether the physical device is wired in to I0.0 or I1.7. Making one change in the Symbol Table should be a lot less confusing than having a fake I0.0 still appearing to work in the rest of the code.
But you can get carried away with symbolic names. How about naming I1.7 in the Symbol Table as "I0.0"? Or worse, "I0.8"? Or even worse, "Q12.9" All of these are valid names if you want. Boy, you could write some seriously confusing code if you wanted to. How about I0.0 named "DB1.DBW42" or "T2" ...? The possibilities are endless.

For John's question, I think the trick should still work regardless of what state I0.0 is in. The CPU will read all the actual input values in to the Process Image before processing OB1. So at that point I0.0 could be TRUE and I1.7 FALSE. However, as soon as the first line of OB1 gets executed, the Process Image value for I0.0 gets overwritten by that of I1.7 So thereafter any code that references I0.0 should see the value currently in the Process Image. The only problem is if any references are made elsewhere in the code to something like PIB0, PIW0 or PID0. There, with the addition of the 'P' prefix, you're asking the CPU to go off and read the true value at that point in time of the Peripheral address IB0 or IW0 etc. This could obviously be different to the value currently stored in the Process Image at the start of the OB1 scan many milliseconds ago. However, this is an issue you have to take in to account regardless of whether an input has failed or not.

regards

Ken.