SLC500 logic, writing at Inputs

Hello all,

I came across the logic of the attached photos where the programmer is using an analog value to write on two inputs.
My guess is that the original intention was to use the two inputs I:3/3 and I:3/4 but these inputs where not available. Instead an analog input was used, and using some compares the programmer wrote on inputs I:3/3 and I:3/4 to "create them".
That is my guess, but what I don't understand is the values used in the compare blocks.

Any thoughts will be helpful.

You're right to be confused and concerned: writing an Output instruction (OTE) to an Input discrete I/O module point is VERY bad practice.

The I:3/3 and I:3/4 points will remain in the commanded state based on those Compare statements (both OFF, as shown) until the PLC completes its program scan.

At the start of the next program scan, the actual state of the Input points will be written into the Input data table, and the points will retain those actual states until those rungs are executed again.

This might functionally work for the purposes of this program, but the proper way to do this would have been to use a Binary data table element, which they also do in parallel (and with the same Bit number, suggesting it was intentional).

Maybe they have an HMI that's directly reading the Input data table and that they could not modify to read the B3:10 word instead.

I'm not completely sure that it will work as desired, though I think it will see the logically commanded value because I believe that network communications are generally processed before the Inputs at the start of the the SLC-500 operating system's cyclic program execution.

They might have also intended to compare the physical Input value to an analog value related to the discrete sensor, but there are almost certainly less confusing ways to do so.

The only reasonable thing I can think of is that the compares are used to shut off the inputs in the right conditions, not really turn them on. Are these rungs in a constantly scanned routine, or maybe a conditional scan to shut one or both off when wanted.

I think a better practice would be to mirror the inputs to a binary word and have the rest of the program check and manipulate those bits.

Also, are these inputs wired to? Or maybe just used for a HMI reading the IO's as Ken suggests?

Find out if the fully open and fully closed switches still physically exist and work. It could be that something has happened to those switches, and those inputs no longer receive the necessary signal. The programmer may have done this to make up for the missing inputs. I would like to know if that did work as intended. I have a feeling it didn't and that is how you found that little nugget.

I've had to do similar things to keep a machine running while we waited on replacement parts to arrive. In those cases, I energized a binary element in parallel with the output, and placed that same element in parallel with the input in the program to act like the physical switch.

Also could be that the limit switches were never installed/wired and the original commissioner had a plane to catch...

The only thing I see wrong with that would be someone looking at the IO cards to see what is on/off to see why something isn't running.

Having a compare turn on the bit in the input image file would work for the program, but looking at the input cards the LED's would not be on. To that maintenance tech/troubleshooter that didn't know about this trick they would start checking the limit switches.

Could someone explain this more? I don't understand how a physical input can be turned on through using compare function. Doesn't there need to be 24V coming from a load going into PLC input to turn input on? Is there something actually plugged into those two I/O points? Why not use binary instead of actual i/o?

alive15 said:

Could someone explain this more? I don't understand how a physical input can be turned on through using compare function. Doesn't there need to be 24V coming from a load going into PLC input to turn input on? Is there something actually plugged into those two I/O points? Why not use binary instead of actual i/o?

Click to expand...

During the input scan (before the program is running), the PLC will write to the "I" words/bits based on real world input conditions it gathers from input points that are not inhibited. Once that is done, the program can (but shouldn't) change the bits in those same memory locations.

When the logic uses an input address location in a destructive instruction, it will change the contents of that memory location for the duration of that program scan.

Keep in mind that those are just memory locations, not the actual input point that you are reading and writing. They're special in that the PLC will make use of them during the I/O update part of its cycle, but won't mess with them during the logic solving part of its cycle*.

*This applies to PLC-5, SLC, and Micrologix controllers and there are exceptions for things like immediate input instructions.

OkiePC said:

During the input scan (before the program is running), the PLC will write to the "I" words/bits based on real world input conditions it gathers from input points that are not inhibited. Once that is done, the program can (but shouldn't) change the bits in those same memory locations.

When the logic uses an input address location in a destructive instruction, it will change the contents of that memory location for the duration of that program scan.

Keep in mind that those are just memory locations, not the actual input point that you are reading and writing. They're special in that the PLC will make use of them during the I/O update part of its cycle, but won't mess with them during the logic solving part of its cycle*.

*This applies to PLC-5, SLC, and Micrologix controllers and there are exceptions for things like immediate input instructions.

Click to expand...

Oh, I see, that's actually pretty cool you can do that. I'm sure there are other less confusing ways, but still good to know about. Thanks man.

A similar way forced on or off outputs can be handled.


If a physical output is forced OFF, but that output is turned 'ON' in the program, any checks of that output will see it ON, even though it is not energized at the after-scan processing. Also, a HMI watching the output will say it's ON when really not.

EDIT: Forced ON outputs may read as OFF if not turned ON by the program also.



Everything is looking at a 'memory map' that is copied to the outputs - unless they are forced - after the program scan, just before the inputs are copied to the 'map'. Forced inputs are recorded in the 'map' as their forced states.

Now thanks to one of Ron's great bootcamp vid's we have this great example of exactly what/why this can happen. With this post we now have a reason why we may see this happen in the real world, even if it would seem a poor coding practice.
https://www.youtube.com/watch?v=B9HYUbyTKhU