Latch or sealed-in?

[mk42]

When I was learning how to code, I organized all my code around the inputs. I would start with my inputs, figure out what conditions I wanted to test, and then each condition had an associated action. If X and Y are true, I want motor A and motor B to start. This lead to a lot of latch/unlatch logic, and things got kinda messy.

Over time, I realized that things generally worked better and were more readable if i tried to organize my l logic around the outputs instead. I thought about under what conditions I wanted a certain output to be on. Each output got one coil, and anything that needed to be included went in the same rung. instead of conditions 1, 4, and 7 each turning on the output, I would have one network where the output turned on if either condition 1, 4, or 7 were true. Eventually I started using state machines to simplify that logic a bit, but it would still be essentially the same.

It's kind of a subtle difference, but it has allowed me to simplify the way I code, and things have become a lot more readable.

 

[Badger]

+1

The immense advantage of Lancie's method comes in troubleshooting. The program doesn't care, it will execute either way. But a good programmer should ALWAYS keep the needs of the next guy trying to de-bug the logic in mind.

In the US we usually call Lancie's arrangement a holding contact. Elsewhere they use the terminology "seal in". Go figure!

here in the UK we used to call it "Self Latching".

 

[jared1085]

OTE latch is preferable where practical as OTE usually promotes clearer code.
OTL often promotes poor programming practices.
Use OTE is latch should clear on power cycle.
Use OTL if latch should be retained on power cycle - e.g. process control and positioning probably warrant OTL (latching) logic.
Operators like to think that cycling power will make the badness go away - not so if OTL was used.
Like global variable and goto, OTL has it's place - when you are old and beaten, you will recognize that place.

 

[the_msp]

The only time I've used latches was in a 22 step sequencer. When all conditions were satisfied to step into the sequencer, step 1 was latched. On the next rung an XIO of that bit was examined and all of step 1's logic was dependent on that. If outputs were required a memory flag bit was set requesting that output. All the outputs at the end were OTE's with multiple XIO's examining which output request bits were set from various sequencer steps. At the end of each sequencer logic, I would unlatch step 1 and latch step 2. This worked well and the only criticism a chartered engineer commented on when looking at the code 5 years later was that IEC 61131-3 states that only 1 step should be active at a time and when using logic like that for 1 scan cycle step 1 and 2 are both active, assuming synchronous IO scan.

 

[James Mcquade]

i think the key to using latch / unlatch depends on several factors.

1. Latch / unlatch bits in only one location. Multiple latch / unlatch bits will be a pain for the next guy.

2. You should always get with maintenance and see what their experience is and how comfortable with debugging code. What do they want to see and how do they like the code to be written?

3. You MUST know how the machine works when you write the code. Experience will teach you the do's and don'ts of programming. There are numerous machines in industry that are written using code based on latch / unlatch commands. Resetting power on those machines using seal in contacts would be a destructive to the machine itself when it powers up.

Ask the question what happens to the machine when the power turns on when it was in the middle of a cycle. Manual controls are often required to reset the machine in an orderly manner based on latch bits.
An oil filter assembly machine is a good example of manual controls after a power loss. It takes 16 hours to reset the machine at a facility i worked in when the power fails.

regards,
james

 

[Lancie1]

Over time, I realized that things generally worked better and were more readable if i tried to organize my logic around the outputs instead.

I went through the same process. I have been saying that here on this site for years. The Outputs are the part that performs the action. Start with those and you won't go wrong. (Besides there are fewer of them to worry about).

 

[mk42]

I went through the same process. I have been saying that here on this site for years. The Outputs are the part that performs the action. Start with those and you won't go wrong. (Besides there are fewer of them to worry about).

It also helps me realize when additional inputs need to be added, or, potentially, if there are inputs I don't need. Sometimes an extra input means the scope shrunk during commissioning and we don't need it anymore, but usually it means that the machine is supposed to do something I don't know about. A good time to ask questions either way!

Lancie1, it was probably you (or at least someone on this forum) who gave me the nudge in the right direction I needed. For awhile I saw that my code wasn't quite the same as other peoples, and they sometimes didn't like it, but no one could put their finger on exactly what they wanted me to change. It WORKED, but they weren't quite happy about it. Turns out that it was because I was essentially solving the problem backwards from everyone else.

I will say, though, that it makes a great programming exercise to code something more than once. I asked our last intern to write a small program input focused, output focused, and then introduced him to a state machine. It amazed him that completely different looking code could produce the same result. The only wrong program is one that doesn't meet the spec, but some solutions are more right than others!

 

[rootboy]

Whenever I use a latch...the next rung is the unlatch logic.
You could latch.... perform logic based on latch.... and then unlatch. But now you have to search to find unlatch.

Yup. There is nothing inherently wrong with a latch. The problem arises in how it's used. For instance, if a programmer comes here and *does not* use a latch for the carrier at stop or stop blocked logic, then they will have to do it over again. Period.

The last thing that I need to do is to have to walk the system after a breakdown, and manually input carrier at stop memories before restarting the line because someone felt that latches were evil.

AB (among others) created this problem by making it easy to bury the unlatch coil anywhere in the program (or to forget to put it in entirely).

In contrast, GE (with the Series Six) made latches, timers, and counters a double rung where the bottom rung held the unlatch or counter/timer reset coils. No latch he!! on a Six, and we somehow muddled through without being able to scatter unlatches to the four corners of the program.

 

[DwSoFt]

I went through the same process. I have been saying that here on this site for years. The Outputs are the part that performs the action. Start with those and you won't go wrong. (Besides there are fewer of them to worry about).

And luckily I learned this here from you Lancie and others at an early stage.

As far as learning better practices. In addition to this site as well as some help from fellow programmers I work with, I have had the pleasure of directing many other people's code in existing installations. I have found good and bad. An picked what I like to use in my code.