Rslogix OSF advice

Hello, what are the benefits of using OTL and then OSF to unlatch compared to just using OTE. The OSF instruction doesn't point anywhere else in the program. Check the images.


I feel like it's unnecessary.


Thanks for any input.

One shots are useful be it OSR or OSF in other words it is a single scan either do something on rising edge or do something on falling edge in the scan rather than during all scans. One shots are useful if the driving bit stays on so rather than keeping its state it is only triggered on rising or falling.
In your pic it probably would not matter but consider the scenario where an input stayed true and you used it to unlatch something, but you need to latch it again while some other input needed to latch it then on a new scan it would be unlatched can be useful if you need to increment a word on a falling edge but the bit driving it stays on.

In the specific case shown, unless the Do_Something bit is scattered through the program in several locations, it would probably be better to go with the OTE method. As parky said, there are many good uses for leading and trailing edge oneshots. But the pictures you posted don't look like one of them.

Keith

Thanks

It could simply be a matter of habit on the programmers part.

Or he could be trying to impress a boss by making it look more complicated than it was and justifying his time/pay.

A good example is a pick and place with two cylinders one for forward & back and one for up/down. you send the cylinder forward and use the forward prox to latch a bit to send it down, at the bottom you need to de-latch it, however, the forward prox is still on so it will try to latch it again. depending on the type of prox either N/O or N/C you would use OSR or OSF. so it only triggers on the transition.

What about edge cases e.g. mode switches and power cycles?

I did a test with a MicroLogix 1100, and although that may differ from the OPs case, it does show that in continuous Run mode there is no difference in the [Do_something] bit behavior.



However, there is a difference between the two approaches in how the [Do_something] bit will behave when switching between run and program mode while the timer is timing i.e. when the .TT bits are 1, and then back to Run. The image below shows the Online state of such a case: OSF-unlatched Do_something is 1; OTE-driven Do_something_2 is 0.

Specifically, when switching back to Run mode:

• In both approaches,
  • the TOF will be set to expired (.ACC set to .PRE) and .TT will be 0;
• in the OTL/OSF/OTU approach,
  • pre-scan will disarm the OSF
    • 0 assigned to both storage and output bits,
  • so the OSF will neither
    • get triggered by the transition of .TT to 0,
    • nor assign 1 to the OSF_OO one-shot,
  • and the Do_something bit will not get unlatched,
  • so the Do_something will keep its 1 value;
• in the OTE approach,
  • pre-scan will assign 0 to the Do_something_2 bit,
  • and the restart will not change it, since .TT is 0

There is also the case of a power cycle to consider, which may be related to the mode switch.



My guess is that Aabeck is right and the original programmer may not have considered any of this.

No need for the one shot or the latch just use the TT contact N/O or N/C it's the same thing
TT set bit
TT OSF reset bit
is the same
as using TT.

To be clear though, the bit stays on because of the nature of OTL/OTU. The OSF is not the reason it stays latched. But the difference between how the OTL/OTU operates versus the OTE is an excellent point that needs to be understood. People often forget about mode changes and power cycles when thinking through their logic. Once you introduce OTL/OTU and even one shot instructions, you really have to plan for and test these conditions.

OG

drbitboy said:

....in the OTL/OSF/OTU approach,

• pre-scan will disarm the OSF
  • 0 assigned to both storage and output bits,
• so the OSF will neither
  • get triggered by the transition of .TT to 0,
  • nor assign 1 to the OSF_OO one-shot,
• and the Do_something bit will not get unlatched,
• so the Do_something will keep its 1 value;

Click to expand...

Operaghost said:

To be clear though, the bit stays on because of the nature of OTL/OTU

Click to expand...

Yes, I forgot to state that explicitly i.e. that bits driven only by OTLs and OTUs* are unaffected, i.e. left alone, by the pre-scan.


* Or maybe I should say bits not controlled by OTEs

Operaghost said:

The OSF is not the reason it stays latched.

Click to expand...

Okay, I get your point, but this is semantics: the way pre-scan handles OSFs is the reason the bit is not unlatched; i.e. the falling edge of the .TT, from before the mode transition to Program to after the mode transition back to Run, is missed, because the OSF storage bit is cleared by pre-scan.


Pre-scan in AB hardware seems to me to be its own knowledge domain. I found a statement once claiming that it is not a scan per se, in that the program is not executed as a whole, but that every rung is "evaluated" as false regardless of the logic instructions feeding it; that is perhaps one convenient way of explaining what pre-scan does with bits driven by OTEs, OTLs, and OTUs. However, that approach does not explain all pre-scan behavior (e.g. timers; counters; ONSs; OSRs; etc.). In the end I think the only way to figure out what happens is to read the manual for each instruction (and hope it is right). Pre-scan is an activity that affects the PLC state, but it is risky to think of it as a scan.

I am thinking the original programmer didn't take everything into consideration.

I worked on a panel unloader that took completed panels off a conveyor and the entire programming of a cycle was done with latch/unlatch for every step of the cycle. The programmer didn't take every possibility into consideration to unlatch everything if the unit was stopped mid-cycle.

Whether it was a power cycle, E-stop or fault - to restart the thing it has to be in the same position it was in when it stopped, and if there was a panel on the conveyor there had to be one when it was tried to restart.

I was going to rewrite the program for them but they ended up scrapping out the thing.