I recently was assigned the task of maintaining several PLC-5/80s that had multiple process program files that were called by conditional JSR
instructions, depending on which process was desired. )The facility is 75 miles from my office and we try to support them via modem to save on the travel time.) Each program file used latch and unlatch coils to keep track where in the process the system was.

However, it was possible (and it often happened) where a partial sequence was executed to do clean-up activities and then the process was switched to
another program file. However, the original programmer did not reset the latch bits when the program file changed and when the first process was called again (sometimes weeks later), the system hung up. I would believe that the original programmer didn't even think that the operators would do only a partial cycle and thus blindly programmed a continuing problem that
required support.

We research this and put in the appropriate unlatch coils in the main program file #2 to prevent this in the future, but I don't even want to think about the hours of lost production and engineering troubleshooting this caused. I certainly avoid using latch coils where an alternative is available.

Russ Kinner
AVCA Corporation
Maumee, OH USA

 

I read this story, and instead of hearing "Evil latching instructions" I hear "Lazy programmer who didn't research all possible outcomes of his ladder". There is a big difference.

I would say that this is simply a misapplication of the instructions in question. Latching outputs do have their place in well written code. However, care must be taken to make sure they do not become a crutch to laziness, poor research, and ignorance of solid problem solving methods.

--Joe Jansen

 

I regularly use latch and unlatch instructions despite being told 18 years ago "never use latch instructions". I also use conditional JSR's. If used correctly both produce smaller, more efficient and more readable programs. Latches/Unlatches are kept within a subroutine and the bits are stored sequentially so they can be summarily reset by a clear instruction. A first pass bit is used in all subroutines. The first pass bit is set in the main program when the routine is not required. In the first rung of the subroutine the first pass bit clears any
variables such as timers, counters etc that need to be initialised for that subroutine, clears all latch bits and of course clears itself. All first pass bits are initialised by the PLC first pass bit.

However, I don't use latched instructions on outputs. One output..... one instruction.

Vince

 

One other issue that we have run into with AB processors and latching coils is that they are retentative instructions and even after a power outpage or major fault, they remember where they were. We have outputs that when power returns start back up.

I realize that in partial this is a programming problem in that the original programmer did not include a "start-up" routine to clear all of these.

Our local AB says that you need to sparingly use latch/unlatch coils and consider all possible actions these may cause (as if this was not a new
thought).

Just my 2 cents, as I am in the process of going through entire projects and looking for all of the latch/unlatch pairs and seeing their issues with faults.

One other note on this thread someone had said that a latch in rung 10 and then an unlatch 50 rungs later could cause sequencing issues........in an AB the io is not updated until program scan ends (unless II instructions etc.) so at least in the case of IO this is not true, does anyone know what about internal bits (IE B bits) if rung 1 says B3/1 is true and then used in rung 2 does the code use the true state or does it wait for a program scan, I assume it uses it and the same for the I/O but actual I/O state is not changed until the end of scan, whereas internal IO is immediately changed in
the data table (I assume this is also true for I/O, the data table is changed).

Thanks just trying to stay on top of this ever changing world....

Dave

 

Dave,

If you have an energized OTL instruction in rung 1 that is turning B3:1/1 on, an XIC B3:1/1 in rung 2, and an energized OTU B3:1/1 in rung 3 turning it off again, rung 2 will see the TRUE condition, ie pass power.

To specify a bit deeper in your comments above, the *INTERNAL* data table for physical I/O updates immediately. In other words, If you take my example above, and replace B3:1/1 with, say, O:1/1, you will have the same results. rung 2 will see O:1/1 as being on. The data table is only transferred to the physical I/O map at the end of scan, so the physical I/O point will always see an off condition. However, If you have an output being turned on early in the program, turned off late in the program, and
being checked for condition in the middle of the program, the condition checks will see it as on, while the actual device will always be off.
(Assuming that the program was poorly written enough to allow both the OTL and the OTU to be energized at the same time).
;->

Hope this helps. I agree that any time that both the OTL and OTU are allowed to be on, it usually indicates poor programming proactices, unless
there is a very specific, and *WELL DOCUMENTED* reason for it to occur.

--Joe Jansen

 

Dave,

If you set a latch on say B:4/0 in rung 2, use B:4/0 to drive output O:3/2 in rung 5, then reset B:4/0 in rung 10, and use B:4/0 again as a normally closed contact to set O:3/3 in rung 12, both outputs will be on - I've done it with SLC500.

Why you would want to do that, beats me - but stranger things have been known to happen ...

I personally don't have a problem with latches, but as I said in my earlier post I like to see the L and U coils in adjacent rungs.

I've also had problems with a make of PLC that allows multiple use of L and U (can't remember the make). Someone left a stray U in the logic that proved to be very difficult to find - he thought he'd cleared out all references.

Bruce.

 

Thanks for the help....this is the way I read that it worked also and have assumed for quite some time. I agree with all of your assesments so far.

I have programmed some systems that have won some awards (Microsoft, Rockwell) and it seamed bizzare to me that they were deamed "cutting edge", "different" etc. and when you came right down to it in my opinion.......they were what I call MOSS....Maintenance Operations Support Systems (paper mill, forest industry ackronym).....whereas management thought they were
OPERATIONS support systems. They think I build these things so the Operator can run the machine and my line is that, that is just a side benefit of my Maintenance Diagnostics system......the Operator can run the plant with it.

I am in total agreement with you and get accused of being too "slow" all the time because I put great detail into my HMI systems and inform Operations and Maintenance what is going on totally with their machine.

I get hammered all the time for wanting things like mag prox switches on hand valves etc. and yet dispite all of their whining.......the machines with the least amount of downtime and trouble are these systems in our plant. And some people still do not see the connection.

I do not want this to sound like some "pat myself on the back" thing because it couldn't be farther from my intention.......I just think like you seam to that it is just common sense. I consider myself one of those "old world" craftsmen who do teh extra "sanding coat" or measure one more time before assembly etc.....

If the arm used to take 3 seconds to extend and now it is taking 4 or 5 inform someone to look at it etc..........

I would really love to exchange more e-mails on phylosophies as it sounds like we are totally on the same page as far as building HMI systems and PLC programming and there are not a lot of us around or at least it seams that way.........

Thanks again...

Dave

 

With AB's I have also unlatched inputs at the end of a rung to setup flip-flops, etc. The IO image does not get updated from the table until the end of scan, so internally the I's and O's are handled the same as B's,etc, but only affect the
output at the IO update. The image update instructions will cause the update to happen sooner.

This works fine on SLC's and PLC's, but not ControlLogix which is why a lot of programmers will map the IO to internal tags.

Cheers,
Trevor Ousey.

 

It depends on what PLC (brand AND model) you are talking about I have seen this changed between different models (of the same brand).

That is also true for "normal" output instructions (ie non latching). and in some PLC:s the behaviour is different for memory and physical
outputs.

| input1 output1 |
|---| |-------------( )----|
| |
| input1 output1 output2 |
|---| |----|/|------( )----|

The above ladder will behave different in different PLC:s and in some PLC:s it will behave different if output1 is a memory or a physical output.

Some PLC:s will give you a short pulse on output2
whenever input1 turns on, others will never turn on output2.


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

In process control latch and unlatch instructions can be very useful if used correctly in that if the power is interupted then the process may well need to restart from the point at which it stopped, hence the latch instructions need to be retentive on power outage.

If it is required that the instruction latches only while power is on then use a standard bit held on by a n/o contact with the same address.

A tip if you need latching bits but occassionaly need to clear them all is to make all the associated latched bits be in one word, eg B3:0/0 to B3:0/15. When you need to unlatch all the bits at once just CLR B3:0

 

Just wanted to add a thought here for something I have seen recently, again. I was recently called in to make a change in a custumer's PLC, which was totally undocumented, and found a similar situation that did not include latches. The system had a series of stop button inputs to the PLC which were all in series in the first rung with an OTE output for B3/0. By being a stop circuit, this was used throughout the program. Upon looking through the program I found the bit was always off, and thus should have never let anything run. After a few seconds of thought and having seen this before, I did a cross reference and found the bit b3/0 used twice with an OTE instruction--the second time for a totally different purpose. The person who added the second reference in got lucky in that they did it at the end of the program and only used the second use of the bit in further rungs. You can use a bit for this dual purpose and it works--extremely bad programming though. The problem in looking at it with RSLogix500 was that it must update the connected PC at the end of the scan so that you only saw the second state of the bit (which was off 99% of the time). So, yes, in allen-bradley plcs, the bit or word value is immediately in use for succeeding rungs.

As a note for other programmers, always refresh and check the cross reference report before adding bit or word addresses to the program.