Use or not Latch/Unlatch instructions

clearly we're not understanding each other ...

the point that I have been making is that not ALL machines cause a "hazardous condition" when automatically restarted after a power cycle ... the NFPA standard that was quoted in Post #11 recognizes that – and makes exceptions for that fact ...

some common examples are life-support systems (such as exhaust and intake air) and pumping systems for water and wastewater handling ... one actual real-world example that I'm familiar with was a large (tourist-level) aquarium where a failure to restart the filtration pumps and ozone generators after a nighttime power failure could have killed many of the innocent little fish ...

now then ...

this thread had been chugging along with different posters advocating for – and against – the use of "latching" and "non-latching" programming techniques as though the main considerations should be the "design" and the "troubleshooting" aspects of the subject ... (something along the lines of "don't wear stripes and plaid together") ...

there is much more to be considered here ...

my point is that "latches" and "seal-in" techniques BEHAVE DIFFERENTLY – and a failure to consider those differences can have catastrophic results in certain situations ...

surely we can all agree on that easily provable point ...

once we've agreed on that point – then the fact that "one size does not fit all" shouldn't be that hard to agree upon too ...
 
Last edited:
my point is that "latches" and "seal-in" techniques BEHAVE DIFFERENTLY – and a failure to consider those differences can have catastrophic results in certain situations ...

surely we can all agree on that easily provable point ...

once we've agreed on that point – then the fact that "one size does not fit all" shouldn't be that hard to agree upon too ...

Agreed...

But we have to mention that they behave differently only on Allen-Bradley PLCs.

I don't know if there are any other PLCs that behaves that way. Most I know just clear the output table upon restart so all real outputs are set to zero. No prescan oddity. So it makes no difference what method you use to set the output.

.
 
Last edited:
Agreed...

But we have to mention that they behave differently only on Allen-Bradley PLCs.

This is incorrect. There are other PLC's where output / coil instructions are retentive by default and some can be set to be retentive or not it's an option.

Also just to note you have said that a PLC should never be able to start anything by itself which is incorrect. In fact there is a plethora of applications where auto restart of certain things is an absolute requirement.

Think Aquariums, Remote pumping stations, Ventilation, refrigeration systems, I can go on for days.

Also as far as safety systems they are not as black and white as some seem to think. Many times when an estop is hit a load needs to turn on not off and in some cases motors need to start or stay running not stop.

It's all very dependent on the specifics of the application and this is why when people try to slap their normal estop and safety relay on every machine they encounter the same way they always have and just kill power to everything you end up with machinery that is in some case more dangerous than it was before you threw on the estop buttons and safety relays.

This is why when we get questions about "what safety relay do I need for my machine" they are difficult to answer because you need to have specific knowledge of the equipment and a risk assessment needs to be done to identify the hazards and be used to determine the best method to handle those hazards to protect people, property, and profits.
 
Hello everyone and thanks for answering.

The reason im writting this topic is because of the following situation:

Lets say I have 6 tanks:

Tank1 - - - - - -Tank6

I can send from tank 1 to tank 2 , but also from tank 2 to tank 3, and i can also send from tank 3 to tank 2.

So tank 2 could be potentialy used by tank1 or tank 3.

So whenever i want to send my sustance from tank 1 to tank 2, I check that tank 2 is not in use and if its not in use, put it in use.

It might happen that another operator want to sent from tank 3 to tank 2, so again the program checks if tank2 is not in use, and put it in use.

So here is the question. What would be better

if :

start tank2inuse tank2inuse
--| |------------------|\|------------------------------------(L)-----

more code ( open valves,pumps etc)


finishoperation tank2inuse
------| |-------------------------------------------------------(U)---


OR

start tank2inuse others Tank2usebyoperation1
--| |-----------------------------|\|-----------|\|-----------------------(OTE)-----
| tank2usebyoperation1 |
--------------| |---------------

more code ( open valves,pumps etc)

Tank2usebyoperation1 Tank2inuse
-------| |-----------------------------------------------------(OTE)
| Others |
----| |-----------
 
At the end of the day, it's all about having structured code that has a pattern, method, philosophy that can be understood fairly quickly. Perhaps not all the detail of it, but at a 30,000 food level lights go on for someone troubleshooting. Once you have that, you could use just about about any instruction and make it fairly easy to troubleshoot. The issue is when code becomes unstructured and logic goes off in tangents.

OTL/OTU gets a bad rap because programmers get lazy and don't realize how much the retentative OTL can negatively impact a system. Usually what happens is that not all conditions for which an OTU should be used are programmed, leaving bits to get stuck and causing issues with trouble shooting because there is no indication that logic is "stuck" anywhere, which could cause bad things to happen.

This post outlines more of my opinion of it, but all-in-all good program structure will determine how easy it is to program and trouble-shoot, not the specific use of any particular instruction used.
 
So here is the question. What would be better


OR

start tank2inuse others Tank2usebyoperation1
--| |-----------------------------|\|-----------|\|-----------------------(OTE)-----
| tank2usebyoperation1 |
--------------| |---------------

more code ( open valves,pumps etc)

Tank2usebyoperation1 Tank2inuse
-------| |-----------------------------------------------------(OTE)
| Others |
----| |-----------


this one better.
 

Similar Topics

Hello All, Can someone see what I did wrong here. My "PA" bit never seems to get energized despite hitting "SOFTKEY7" many times
Replies
5
Views
764
Hi guys, I have a question regarding studio 5000 with processor 1769-L33ER V33.011 and Factorytalk View SE V12. I have an home-made pop-up...
Replies
3
Views
1,606
I'm troubleshooting a machine for a customer right now, and the output that is not working needs this bit to go high to activate the coil. But the...
Replies
36
Views
13,614
I am trying to convert an old PLC5 program. I have several instances in the unlatch instruction where they give a B file on top of the unlatch...
Replies
9
Views
2,045
Hi everyone. First time poster here. I am very new to PLC programming (my programming background is more in computers). I have a question with...
Replies
12
Views
3,325
Back
Top Bottom