Another consideration if you want to use S:FS to reset latched bits....
Each
Program has its own S:FS bit, that is acted upon on the first pass
of that program.
If an early program inspects a latched bit from a program that is later in the program schedule, or from a program that is inhibited, that bit will not yet have been reset by the S:FS code.
This could lead to unexpected operation.
My pictures show two programs, Program1 and Program2....
Both Program1_BitBox and Program2_BitBox are controller-scoped tags...
I start, in Program mode, with both bits toggled ON, and Trap_Bit OFF.
When I change to RUN mode, you can see that Program1 sees Program2_BitBox as ON, and latches the Trap_Bit. It is not until Program2 is executed that Program2_BitBox is unlatched.
This could have dangerous consequences, depending on how the bits are inter-related between programs.
As Ron has pointed out, it's a case of "horses for courses"... If you definitely want a bit to be turned OFF when the processor enters Run-mode, then program it as "seal-in" latch logic. If you definitely want the bit to retain its state when the processor restarts, then use OTL/OTU combinations of the bit in your logic.