easy question, I think...

[Skidood 0]

Hi,  I have a MicroLogix 1200 and an existing program.

I need to add a rung where one of the outputs gets energized when a certain input is ON, (its a float switch)  and de-energized when the input is OFF.

However, the same output is being latched OFF  by other instructions in the program at certain  times.  What would happen if I add my rung which may at times command this output ON while it is currently unlatched  by another part of the program?   Will the program  execution fault out/hang?  

[Joe E. 259]

In a MicroLogix, the result of the last scanned instruction that changes the memory location in the output table is the one that gets sent to the output module.  IMHO, if your program uses latches and unlatches (and especially if it uses multiple OTE coils) to control an output, it needs to be re-written.

[Michael Lloyd 85]

If the latch / unlatch output logic is preceded by a one shot, positive edge trigger, whatever you want to call it then you can probably make it work BUT... I agree with Joe E. Multiple latch / unlatch rungs for the same output sounds like a kludge.

Edited 30 Mar 2017 by Michael Lloyd

[Skidood 0]

Hmmm..you lost me at  "that changes the memory location in the output table"   

The program has about 25 instances of this 1 particular output being latched or unlatched under certain conditions or parts of the execution cycle..the machine runs a very elaborate program for being in a 1200.   The rung I am adding monitors a float switch during the whole program execution and has to activate an output (actually 2 not 1)  whenever  the float switch input is OFF. 

I'm an amateur...so...I assume the attached graphic depicts a latched output.

 

(oops there is supposed to be a "L" in the brackets below) 

 

Edited 30 Mar 2017 by Skidood

[Skidood 0]

I think that as the program executes, and travels along its merry way, any one output is never controlled by another part of the program but I am adding a potential crash, since I am wanting to command an output that may already be unlatched by some other program step. 

[Michael Lloyd 85]

Just now, Skidood said:

Hmmm..you lost me at  "that changes the memory location in the output table"   

The program has about 25 instances of this 1 particular output being latched or unlatched under certain conditions or parts of the execution cycle..the machine runs a very elaborate program for being in a 1200.   The rung I am adding monitors a float switch during the whole program execution and has to activate an output (actually 2 not 1)  whenever  the float switch input is OFF. 

I'm an amateur...so...I assume the attached graphic depicts a latched output.

 

(oops there is supposed to be a "L" in the brackets below) 

 

That's not a latch, that's an output coil that is energized

A latch would say OTL. Unlatch would say OTU

[Skidood 0]

OK awesome..thanks...I think I will be good.

[Joe E. 259]

Maybe more info than you need...

All output instructions act (or don't act...see below) on a memory address.  OTE, OTL, and OTU are bit-level instructions which means that they act on a bit.  They don't care what that bit is or where it is.  It can be O:4/5, I:3/2, N7:8/5 or B3:15/4. It doesn't matter.

An OTE instruction uses the solution of the logic in the rung to write the addressed memory bit to either a "1" or a "0".  On EVERY scan of the rung containing an OTE instruction, the memory location will be updated.  If the logic is "true", the memory location will be written to "1".  If it's false, it will be written to a "0".

An OTL instruction uses the solution of the logic in the rung to decide whether or not to write a "1" to the addressed memory location or not.  If the logic solves to "true", it writes a "1" to the memory location.  If it's "false", it does nothing.

An OTU instruction uses the solution of the logic in the rung to decide whether or not to write a "0" to the addressed memory location or not.  If the logic solves to "true", it writes a "0" to the memory location.  If it's "false", it does nothing.

In most PLCs (I'm sure about the Siemens S7 series, Allen-Bradley PLC-5 series, and Allen-Bradley Logix 500 series), the PLC operates like this once it's running:

1) Use the physical input modules to update the "Input" memory area of the processor.

2) Execute logic, reading and writing memory locations as the instructions dictate

3) Use the "Output" memory area of the processor to update the physical output modules.

So, knowing that, we can follow the logic flow through the program.  If rung 1 has an "OTE" instruction writing O:4/5, and rung 2 has an "OTU" instruction writing the same address, then the OTE will control the output UNLESS the logic in the OTU rung solves to true, at which point the output will always be "off" in the real world.

PLC instructions don't care what memory address you use. An "XIC" or "XIO" instruction can read the status of an Output memory address and an "OTE", "OTU", or "OTL" instruction can write to the "Input" memory area. 

One of the problems you'll run into if you have a lot of places that write to the same address is that your online monitoring with the PC won't necessarily tell you the whole story.  IOW, if you have an address that's written to in rung 1 and in rung 17, the status that the PC displays will be what it was set to in rung 17 (I think...), which may confuse you if it's read in rung 10.

You may find the sample training videos here useful:

http://ronbeaufort.com/main_frame_page.htm

By the way, the Allen-Bradley Logix 5000 class of processors (ControlLogix and CompactLogix) don't work the same way as all the others.  With the 5000 class processors, the input and output memory areas are updated independent of the program scan.  They call it "asynchronous" updates.  This means that, without the PLC code writing to the input memory at all, an input address can change state part way through the execution of the code.  The timing of the update is completely unpredictable.  Most of the time, that isn't an issue, but there can be some gotchas and race conditions if you're not careful.  Some programmers will have read the input addresses to internal tags at the top of the scan and write other internal tags to the output addresses at the end of the scan, creating their own "scan buffer".  I've never had to do that, but I've seen it done.