Programming style question - latching in various situations

Hi all,

I've been reading up on latches vs seals. I am working with SLC500's. From what I understand, the only thing to be aware of regarding latches in AB SLC500's is that the latched bit will remain on even after a power failure, and a sealed in bit won't. At least that's what I gleaned from reading Ron's big latching post (I think it was Ron, my apologies if I'm wrong).

I have a few questions about latching vs using seals in different situations:

1)Fault handling
It seems to me the easiest way to do this is by latching a bit. Using a seal is more difficult as a fault bit is usually used in at least 2 different ladder files (the fault file and the file where the fault originated). Is there any reason not to use a latch for fault bits?

2)Real world outputs
Depending on whether or not you want the output to remain on after a power failure(assuming it was on before power was lost). If you want it to remain on (ie: retentive) after power failure, use a latch, otherwise use a seal

3)Sequencing
Again I've always heard not to use latches for sequencing, instead I've been told to use sealing. If the only difference is whether or not you want the sequence bits to retain their state in a power loss situation, this seems somewhat trivial, or at least not a good enough reason to never use latches in sequencing (I mean, a simple unlatch of all the sequence bits using the first scan bit will do the same thing right?). I've been told that using sealing is better because when using latches in sequencing bits, somehow the program has more of a tendency to get "stuck" or that by using sealing for the sequencing bits it's more "flexible" or I've even been told that the program can go "backwards"(which was said in a positive manner. I think the intention was to mean that if the sequence went one step too far for some reason, you were able to move back to the previous step without going online with the plc or something to that effect)

Maybe someone could clear this up for me. Particularly the sequencing part.

Thanks a million.

Use what you understand.

Understand what you use.

There are folks who refuse to use latch/unlatch, they claim it is the root of all evil and should never be used. I use it quite a bit. If the logic is easier to understand, if it's more maintainable, or more robust, I'll use what works. It's not a simple one or the other choice.

I'd have to see the example of a real output programmed as a latch/unlatch pair to comment on it. I can't think of any offhand that would require it.

As far as sequencing goes, it's even worse than latch/unlatch for strongly held opinions on how it should be done. Real examples are needed to have any useful discussion on the pitfalls of various approaches. All of them work if done properly, and all of them can be butchered by someone that doesn't understand what they are doing. My personal opinion is that sequencer instructions hide too much of what is going on in the sequence tables and require much more documentation to effectively troubleshoot. They are an emulation of an archaic mechanical device. However, if it fits your project, you should use it. Too many people use it simply because it has "sequence" in the name of the instruction.

And why do some people use N7 integer addresses for latches vs B3 bit addresses?

I think I was misunderstood. I didn't mean using the sequencer instruction. All of my examples (questions really I guess) are based around the difference between a simple rung with an output bit and using that bit as a "seal" around the input vs using a latch (L)

mellis said:

Use what you understand.

Understand what you use.

There are folks who refuse to use latch/unlatch, they claim it is the root of all evil and should never be used. I use it quite a bit. If the logic is easier to understand, if it's more maintainable, or more robust, I'll use what works. It's not a simple one or the other choice.

I'd have to see the example of a real output programmed as a latch/unlatch pair to comment on it. I can't think of any offhand that would require it.

As far as sequencing goes, it's even worse than latch/unlatch for strongly held opinions on how it should be done. Real examples are needed to have any useful discussion on the pitfalls of various approaches. All of them work if done properly, and all of them can be butchered by someone that doesn't understand what they are doing. My personal opinion is that sequencer instructions hide too much of what is going on in the sequence tables and require much more documentation to effectively troubleshoot. They are an emulation of an archaic mechanical device. However, if it fits your project, you should use it. Too many people use it simply because it has "sequence" in the name of the instruction.

Click to expand...

OK,

Provide some examples and we can discuss them. If you're looking for examples, use the search. There are plenty.

As to the N7 vs B3... Bits are bits. They both work. B3 has an odd addressing mode that can sometimes be useful. The B3/176 form. B3:11/0 is the same address and works the same as N7:11/0.

How is the odd B3 addressing mode useful?

I once worked on a machine that was programmed completely with latches and oneshots. The thing had an intermittent input problem and the style of programming made troubleshooting a pain.
Moral: Anything can be made to work but it doesn't mean it is a good thing. Whatever style of programming you feel comfortable with is good but think about the sod who has to figure it out later when the documentation is gone and the impossible failure happens.

Use what you understand.

Understand what you use.

Click to expand...

this sums it up.

the only difference between B and N files is default view (in the data table or in the code when you are not using it as a bit).

The Plc Kid said:

How is the odd B3 addressing mode useful?

Click to expand...

In some PLCs we have some valves we are controlling. There are many valves (over 100), and they are numbered sequentially.

If I want to toggle valve 40 (assuming we ignore bit 0), it is much easier to say:
Latch the bit B86/40

than to calculate
B86:2/7 from 40

There are many other instances similar to this where it is easier (and easier to understand) to use the absolute address of a bit than the Word / Bit reference, especially when you make use of indirect addressing where things have to be offset similarly from one another to keep standardization in your memory mapping.

The reason some folks abhor latching:

You open a program to troubleshoot.

You find a bit address that is not in the correct state to allow the next function to occur.

You right click, and hit find all, and there are 11 OTU instructions and 3 latch instructions scattered among several ladder files.

In back tracking, you find dozens of bits that each have multiple OTU and OTL instructions. Now you are lost and frustrated trying to figure out what the original programmer was trying to accomplish. Perhaps there is a method to the madness, but meanwhile, your regard for the programming style in use has plummeted. You make a mental note to avoid this style of programming in the future.

There are plenty of real necessary uses for latching instructions. There are plenty of optional but functionally clean and effective uses for them as well.

If you are concerned that your style will be misunderstood, then you are probably correct. Either document it clearly or change styles.

My 2 cents.
Paul

Great explaination Paul, been there more then once.

So that leads me to my one exception: If you use a latch/unlatch, only use ONE latch and ONE unlatch.

Makes troubleshooting much easier.

If you use a latch/unlatch, only use ONE latch and ONE unlatch.

Click to expand...

and then stick them in rungs next to each other!