Interesting ordeal with Omron CX Programmer.

I just got done doing a small upgrade to a program running on an Omron CS1G-H PLC. It was a very simple program change but ended up taking me a good two to three hours to find out why it wasn't working.

All I had to do was put a contact in a single rung, addressed to an input, so the output coil would not turn on if the input was off.

So I begin an edit, insert my contact, address my input, send changes. I go to test out the new program, and I turn off the input. The rung goes false, but the output coil remains energized in the program (illuminated green). Confused, I tested out many things. If I turned off the input physically, the rung would go false but the coil would remain energized. If I forced the input off in the program, the output coil would de-energize.

After a while of researching, troubleshooting, searching the program for duplicate coils, etc. I decided to search for the input in the program. Turns out someone before me had made an Always true Output coil addressed to this input.

So while monitoring the program with CX-Programmer, the state of monitor would follow the physical input, but the logic would follow that the input was always on because of the output coil addressed to it. CX-Programmer would show the input go false, and any rungs with that input as a permissive also go false, but the PLC itself would actually make it true, and keep the output coils true.

Very confusing little bug.

obviously not a good programmer of omrons preceded you.
253.13 or 253.14
Omron has it's own always off or always on system contacts,
they differ in the latest plc's but they are their.
the entire range of system contacts are very useful

obviously not a good programmer of omrons preceded you.

Click to expand...

Or not a very good programmer in general...

Probably a NAPA
Not A Programmers A_h

Pretty obviously a poor programmer prior to me. If they really wanted to bypass this input the way they did they could have done so without program changes. Physically jumping out the simple 24V input and making note in the prints, or by simply turning on the Force.

But it is a bug in the CX Programmer software as well. It displays a logically false condition yet shows the result true. I thought for sure it was because something else was writing to the output bit. Never crossed my mind that it was because someone was writing to the input bits.

Just an example of what was shown:

Input On, Rung True, Output On

---||---( )---

Input Off, Rung False, Output... Still On.

---||---( )---

Input Forced Off, Rung False, Output Off.

---||---( )---

The monitored value of the input displayed in CX programmer was not the same as the logical value of the input being used by the PLC. All because someone addressed the input with an output instruction and was setting it to a "1".

Just wondering Tharon, was the I/O rack setup in the config area ?
you can use any numbers for inputs or outputs because of the numbering range of omron, but I am thinking if the 0.00~0.15 is configured as an Input card I think it wont let that happen.

well I have checked it out - I am wrong -

I'm not very familiar with Omron PLCs or CX Programmer in general. I haven't created programs from scratch, only used CX Programmer to monitor existing programs to understand them better, and to make small changes to machine operations.

The Input was mapped to 0.13, and in the symbol table is says it's Main Rack Slot 00, Usage: IN.

The rung turning it on was:
LD P_On
OUT 0.13

Always True, turn on 0.13