unlatch command in allen bradley

i say nay nay!

Actually, the ons was very important when the HMI was Wonderware.

I'm not exactly sure right now, as to the why, but I can definitely attest to the fact that b3/1 would be on for more than one scan w/o the ons.


I think that the hmi would continue to set the n7:0/1 until comms were complete.

So, actually, it took a couple of plc scans before n7:0/1 was reset.

The example I gave works with Wonderware. We use the Set type of push button. This writes a 1 just one time. If you use the Direct button type, it will write a 1 as long as the button is pressed. Having HMI set the bit and the PLC unlatch the bit is the preferred method for Wonderware.

gmferg said:

The example I gave works with Wonderware. We use the Set type of push button. This writes a 1 just one time. If you use the Direct button type, it will write a 1 as long as the button is pressed. Having HMI set the bit and the PLC unlatch the bit is the preferred method for Wonderware.

Click to expand...

I'm not going to continue this argument.

Someone posted code and wanted to know why anyone would do this.

Since I recognized it from the oil fields, I replied.

Never did alot of HMI this is an interesting thread.

ganutenator said:

someone on this forum about 6 years ago, displayed a way to do this logic on the word level by using an XOR instruction.

It was a clever way to oneshot many hmi buttons.

Click to expand...

Now that is clever..............

The HMI I am using does an invert bit and a set or a reset. BUtit also acts like a retentive bit. If you use the reset it holds the bit low. I want it to just turn it off once or on once and at other times I would like one press on, next press off.

I have found ways to do these things just relating my situation.

Of course there is more to it that I have to discover as I have used Siemens for 3 months. (WinCC)

One neat thing about WinCC is the press and release can be used independantly. I use press to set X and release to reset for a momentary.

dahnuguy said:

and I miss the OSR too. Siemens has a POS which goes true on the positive edge but it stays true ...........they may have a true one shot rising , but I haven't found it yet.

Click to expand...

The POS (and NEG) are true one shots. You have to think in terms of RLO, and the RLO is true for exactly one scan. For instance:

A I 1.0
FP M 10.0
= M 10.1


In this case, M 10.1 is your one shot. Actually, you could even set multiple one shots, or call additional functions instead. Again, it's all about the RLO, with any logic initialized by either the FP or FN being true for only one scan..

here’s one thing that I haven’t noticed in all of this discussion so far (sorry if I just missed it - I’m short on time lately) ...

for most HMIs a “momentary button” action actually consists of TWO actions - not just one ... specifically, the HMI first sends a “turn-ON-the-bit” signal to the PLC - and then later (when the “button” is released) the HMI sends ANOTHER/SEPARATE signal to tell the PLC to “turn-the-bit-OFF-again” ...

in some situations this can lead to nasty scenarios when the button is being pressed - but then a power failure or a communications error suddenly occurs ... that can lead to “issues” because the HMI isn’t able to turn the bit back OFF - and so the bit gets “stuck” in the ON condition ... even when the HMI eventually gets back “online” again, it usually has no reason to gracefully “recover” and send that all-important “turn-off-the-bit” signal to the PLC ...

many experienced PLC programmers go to the effort of including a special “power-up reset” type function so that the processor is able to automatically “unstick” certain “critical” bits that might have been left in the wrong state when the HMI dropped off the line ... naturally this technique has to be very carefully thought out to keep things safe and reliable ...

my point:

sometimes the techniques used by experienced programmers don’t seem to make much sense - as long as you only think about situations where the sun is always shining, the birds are always singing, and life is always lovely ... but certain puzzling “why-on-earth-did-he-do-THIS-for?” chunks of code are sometimes inserted to gracefully take care of weird “once-in-a-blue-moon” occurrences like power failures and sudden losses of communications ...

I wonder if maybe that’s what some of the techniques being debated in this tread are all about? ...

party on ...

true one shot...........what are the others?

S7Guy said:

The POS (and NEG) are true one shots. You have to think in terms of RLO, and the RLO is true for exactly one scan. For instance:

A I 1.0
FP M 10.0
= M 10.1


In this case, M 10.1 is your one shot. Actually, you could even set multiple one shots, or call additional functions instead. Again, it's all about the RLO, with any logic initialized by either the FP or FN being true for only one scan..

Click to expand...

When I tried using the POS instruction, the RLO stayed true after the input to the POS was removed , leading me to believe it was actually different from the one shot I had used before. Of course this may have been due to some other issue at the time. I don't spend much time argueing with S7 anymore I just do it another way and move on.

And the ONS doesn't require 2 memory locations, it requires none as I recall.

.....[ ].......[ons^]..........( )

Of course one can use a STAT in S7 and not actually use a memory location.

I was using the LAD version of POS, not sure if that matters.

The RLO bit seems obvious to me, I am wondering why you emphasize it so much. Is there some way to miss the RLO? It feels like I am missing something big or I am not, but you think I am. Either way I can't see which it is at this point.

I can see S7 being a lot of fun in a year or so.

I will revisit the POS instruction based on your information, I must have made a mistake somewhere before. I can certainly use the one shot functionality.

Thanks

Ron Beaufort said:

here’s one thing that I haven’t noticed in all of this discussion so far (sorry if I just missed it - I’m short on time lately) ...

for most HMIs a “momentary button” action actually consists of TWO actions - not just one ... specifically, the HMI first sends a “turn-ON-the-bit” signal to the PLC - and then later (when the “button” is released) the HMI sends ANOTHER/SEPARATE signal to tell the PLC to “turn-the-bit-OFF-again” ...

in some situations this can lead to nasty scenarios when the button is being pressed - but then a power failure or a communications error suddenly occurs ... that can lead to “issues” because the HMI isn’t able to turn the bit back OFF - and so the bit gets “stuck” in the ON condition ... even when the HMI eventually gets back “online” again, it usually has no reason to gracefully “recover” and send that all-important “turn-off-the-bit” signal to the PLC ...

many experienced PLC programmers go to the effort of including a special “power-up reset” type function so that the processor is able to automatically “unstick” certain “critical” bits that might have been left in the wrong state when the HMI dropped off the line ... naturally this technique has to be very carefully thought out to keep things safe and reliable ...

my point:

sometimes the techniques used by experienced programmers don’t seem to make much sense - as long as you only think about situations where the sun is always shining, the birds are always singing, and life is always lovely ... but certain puzzling “why-on-earth-did-he-do-THIS-for?” chunks of code are sometimes inserted to gracefully take care of weird “once-in-a-blue-moon” occurrences like power failures and sudden losses of communications ...

I wonder if maybe that’s what some of the techniques being debated in this tread are all about? ...

party on ...

Click to expand...

good points Ron.................I always assume there is something I don't know when something doesn't make sense. That's the most common explaination. After all when something seems out of place it is just our minds comparing the new bit with we have seen before as a reference. I like the reset in the PLC , removes the need to go looking in 2 devices for what should be happening.


Most of the buttons I dealt with were real buttons.

My angle is / was to make the HMI emulate a real button, your point about comm dissruption makes me reconsider this approach.

gmferg said:

The example I gave works with Wonderware. We use the Set type of push button. This writes a 1 just one time. If you use the Direct button type, it will write a 1 as long as the button is pressed. Having HMI set the bit and the PLC unlatch the bit is the preferred method for Wonderware.

Click to expand...

I always thought "set" would write a 1 and leave it a 1 until reset.

Toggle seems like it would be the thing to use to emulate a momentary PB.

I like the "toggle" the SLC500 has in the software online easier to use in places where force on , force off, takes too long.

Looks like this code is doing just that. WIll the HMI "toggle" a bit?

In WinCC I have invert, set, reset,

dahnuguy said:

When I tried using the POS instruction, the RLO stayed true after the input to the POS was removed , leading me to believe it was actually different from the one shot I had used before. Of course this may have been due to some other issue at the time. I don't spend much time argueing with S7 anymore I just do it another way and move on......

I was using the LAD version of POS, not sure if that matters.

The RLO bit seems obvious to me, I am wondering why you emphasize it so much. Is there some way to miss the RLO? It feels like I am missing something big or I am not, but you think I am. Either way I can't see which it is at this point.

Click to expand...

I mentioned it because it sounds like you were confusing the RLO with the STA. With the FP (or POS) instruction, the STA will remain at one as long as the input is true, but the RLO will be true for only one scan.

In any event, the one shot will work as you would expect. I'm not sure what you were seeing before. Maybe you were using the same bit twice or something. Btw, in the LAD instruction set, the POS and (P) instructions are indentical except that the POS contains an extra instruction so the editor can display a little box.

dahnuguy said:

I always thought "set" would write a 1 and leave it a 1 until reset.

Toggle seems like it would be the thing to use to emulate a momentary PB.

I like the "toggle" the SLC500 has in the software online easier to use in places where force on , force off, takes too long.

Looks like this code is doing just that. WIll the HMI "toggle" a bit?

In WinCC I have invert, set, reset,

Click to expand...

"set" would write a 1 and leave it. immediately after it has been set it could be alterted by other means such as other hmi or logic. the set instruction is like you turning on a light in a room and then leaving the room anyone can walk in after you and turn it off again. the "normal" ote coil is like you turning the light on and remaining there with your hand on the switch prevent anyone else from touching it.


the only problem with emulating a pushbutton is that you require two comms event, one to turn the bit on and then a short time later one to turn it off. I like (i think it was Ron's post) to just set the bit on and then let the plc clear the bit a scan or two later.

I agree. Although a lot of HMI packages come with various types of buttons (not to mention hand-made GUIs), I resort to what always works: Let the HMI set the bit (a "request"), and let the PLC reset the request whenever it gets to it. If the button should display some kind of feedback as to whether it is pressed or not, then I provide a seperate feedback state from the PLC. This really makes life a lot easier on systems where there are multiple types of GUI clients and they all need to work the same.

dahnuguy

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

"You need AN unlatch somewhere"

True.

And a false OTE will not unlatch a latched bit in my experience..........

Click to expand...

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.

I like the idea of turning off the hmi bit to avoid comm hangups. I've seen hangups a few times over the years. I can even emulate it in wonderware. Click on a button that's set for momentary, then use Alt-Tab to switch to another application. Wonderware loses focus but the button sticks on. Or if you have a hot-key setup in wonderware to switch windows, it will do the same thing.

So, given that, why would anyone use OTU on each individual HMI bit? Seems like excessive programming. If you put your hmi bits in a contiguous data file (as any good programmer should do, IMHO), then wouldn't a single FLL 0 suffice at the end of the program? Just wondering.....

robertmee said:

So, given that, why would anyone use OTU on each individual HMI bit? Seems like excessive programming. If you put your hmi bits in a contiguous data file (as any good programmer should do, IMHO), then wouldn't a single FLL 0 suffice at the end of the program? Just wondering.....

Click to expand...

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....