unlatch command in allen bradley

No, it won't.

What if the HMI wrote a command to your contiguous file just before the FLL instruction, but AFTER the rung where the bit is tested. Result - lost command....

Good point. However, do comm servers write asynchronously to the data tables? Or are read/write requests handled at a particular timeslice or point in the scan? I know the answer for some processors and the FLL at the end of the scan (maybe FLL is a bad acronym 'cause I'm not necessarily talking AB) would work.

I think there is still a better way than the multiple OTUs. Copy the table at the end of one scan. XOR it with the COPY the next scan.
 
Last edited:
That makes sense.

Back in post #24 (page 2) you wrote....

Sorry to have to correct you here, but a false OTE will certainly unlatch a "latched" bit.

Whether it stays off is entirely dependant on the rung condition(s) driving the OTL instuction when it is next scanned. It may get "latched" on again if the rung is true.

I believe you have made the assumption that the bit actually knows that it was latched, or unlatched, and will not respond to an OTE instruction. That simply is a false assumption. Each bit is written to by the execution of the ladder at the time it is encountered during the program scan. Whether a bit is written or not is dependant upon the instruction it is attached to.

I deliberately put speech marks around the word "latched" above, to emphasise the point that the bit does not know that it was latched, it is simply written to by the logic processor according to the rules of the instructions.

OTE - writes 1 or 0 dependant on the "logic-continuity" of the rung - True or False respectively
OTL - writes 1 only, and only if the rung is true
OTU - writes 0 only, and only if the rung is true

Here is an example by way of explanation....

Say rung 50 has an OTL, and the rung is true, then the ladder processor will write a "1" to the data bit. If the rung goes false, the OTL instruction does nothing to the bit.

If absolutely nothing else addresses that bit (as a rung output), then it will stay latched forever, even if the rung with the OTL goes false. In other words, an OTL instruction only writes "1"s.

Now, say, rung 60 has an OTU of the same bit, and that rung is also true, then the ladder processor will write a "0" to the bit. Likewise as with the OTL, an OTU instruction can only write "0"s to the data bit.

Now, imagine both rungs 50 and 60 are true, then what will happen is that rung 50 will turn ON the bit, then rung 60 will turn it off again. If you are inspecting the bit asynchronous to the program scan (eg. RSLinx) you will see it both on and off, at different times.

Oh and finally, as i said, a false OTE will "unlatch" a bit, but so will a true OTU, and the latter is cheaper in terms of memory usage and execution time, since you need another instruction on the rung to make the OTE false.

Sorry to rant, but I want everyone to understand the priciples of how the processor scans the logic, writing to the data tags as it goes.

See this post illustrates one of my issues with the public forums.....

Why say "sorry to have to correct you here"?

I am pleased to have your clarification and add it to my understanding.

And "sorry to rant" just doesn't fit here..............I see no rant. Just a series of well thought out examples.

To address your content..........As I said before I never use multiple coils and so I don't recall using an OTE with and OTL but I have seen it done with varying degrees of success.

I never thought about the OTU and OTL actually being just half of the OTE.

I guess I had thought the "Latch"was actually a latch and would hold the bit true until specifically "unlatched" by a UTL or a 0 moved into the memory bit.

This is a valuable detail to be aware of.

This also strengthens my arguement against multiple coil assignments. It is worse than I thought.

I use the OTE to make a latch and then break the latch circuit with a reset bit. This way it really is latched until I want it not to.

My experience with OTL and OTU have been mostly cleaning up the mess left by others who used them too frequently and without regard to the consequences. I never "fixed" anything that was working, so if I touched it, it was broken. Sometimes what they wrote worked originaly but then after 5 people had modified it over the years, the multiple errors added up.

This goes under the "I can't believe I missed that detail" folder.

I must apologize for having to thank you for this perspective.

I am sorry to rant about agreeing with you............🍻:D:D
 
robertmee

I go for the "Keep it Simple" approach :-

comms_bit        internal_bit comms_bit
----||----------------( )------(U)-



..that way you know the internal bit will be on for a complete processor scan, and nothing else the processor does (barring a crash, major fault, power-loss or a mode-change) will interfere with it.

If the processor allows it (and A-B does), I put it all in series on the rung, as above, with no branches, minimising code space, and optimising execution time.

It is easy for everyone to see what the rung does.

The approach works for processors with asynchronous or synchronous comms.

The HMI or SCADA only has to perform a "write" operation, so comms overhead is minimised.

New commands can be added at any time, without having to worry about checking to see if they will be cleared at the end of scan.
 
So simple it looks too easy

I go for the "Keep it Simple" approach :-

comms_bit        internal_bit comms_bit
----||----------------( )------(U)-



..that way you know the internal bit will be on for a complete processor scan, and nothing else the processor does (barring a crash, major fault, power-loss or a mode-change) will interfere with it.

If the processor allows it (and A-B does), I put it all in series on the rung, as above, with no branches, minimising code space, and optimising execution time.

It is easy for everyone to see what the rung does.

The approach works for processors with asynchronous or synchronous comms.

The HMI or SCADA only has to perform a "write" operation, so comms overhead is minimised.

New commands can be added at any time, without having to worry about checking to see if they will be cleared at the end of scan.

I like this solution but it depends on a midline coil.........correct?

I dont recall the AB having a midline coil, but I can use this in S7.

A good example of what I had before shaping the way I think now.

Simple nice..........I like it.
 
If a mid-line coil is not allowed on your family of processor, then the following will work just as well.


comms_bit        internal_bit 
----||----------------( )----
|
| comms_bit
+---(U)----


 
If a mid-line coil is not allowed on your family of processor, then the following will work just as well.


comms_bit internal_bit 


----||----------------( )----
|
| comms_bit
+---(U)----


I have no doubt that it will work. Just seems excessive to have that for each HMI command bit. I'm sure the overhead for an additional branch and OTU is not much, but it's still something. And yet maybe less than a single copy and file XOR. The benefit I see with the copy/XOR is that I can predefine a range of HMI bits with plenty of spares. Then, as I or anyone else for that matter adds additional control bits, they are inherently taken care of.
 
I have no doubt that it will work. Just seems excessive to have that for each HMI command bit. I'm sure the overhead for an additional branch and OTU is not much, but it's still something. And yet maybe less than a single copy and file XOR. The benefit I see with the copy/XOR is that I can predefine a range of HMI bits with plenty of spares. Then, as I or anyone else for that matter adds additional control bits, they are inherently taken care of.

Have shaky comes and that unlatch comes in real handy. Place I used to work had a bunch of Panel Views in some realy nasty enviroments and comm loss was pretty regular. When the machines where speed up scan time became an issue (PL5/15 were the PLC's used). A programer removed the resets to reduce scan and all kinds off "weird" events started happening. Note: Comm's was handled thru DH+. To correct and and prevent freaky states we added a Mov 0 to several bits used as buttons on the HMI's. Due to our reaching the end of the capabilities of this peticular PLC programing had to be extremly precise.

One thing to remember, a bit is going to do "exactly" the last thing you told it to do. Because of this HMI Comm's can cause really odd things to happen. Hince in my opinion it is good practise to clear the bit in the PLC.

As Ron said the "once in a blue moon" can get you.
 
Just curious....On most popular HMIs (WW, SE, RSview, Citech), if you configure a button as Set or Momentary On (different vernacular depending on package) and hold the button down, does the SET command get sent to the PLC once or over multiple times? The reason I ask, is that there are often times where an HMI button is Oneshotted. If you are unlatching it in the PLC, and the HMI sets it again, it would be akin to multiple taps of the button.
 

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
707
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,534
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,540
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
1,999
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,187
Back
Top Bottom