Let us go back to the OPs post and do a bit of analysis.....
Say you have several rungs that simply unlatch and latch the same bit.
So rung 1 latches it
Rung 2 unlatches it
rung 3 latches it etc
Now pretend the bit that is being latched and unlatched is the trigger for some other operation
Presumably there are conditional instructions on all these "latch/unlatch" pairs of rungs, and if they are both evaluated as "true", then the bit will be immediately unlatched after it was latched in the previous rung.
So if you want the bit to trigger "another operation", then it needs to be ON, so that it can be seen by that operation. Latching it ON in rung 1, and OFF in rung 2 means that it is only ON during the small amount of scan time between rungs 1 and 2, and OFF for the rest of the scan.
IF, and it's a big if, that is the case, then simply reversing the rung order ought to do the trick, so the bit will be ON for a whole scan before it is unlatched again in (the now) rung 1.
It sounds as though your code is not well-written, and without seeing it, we cannot advise better, but IMHO there are not many cases where you can't dispense with Latch/Unlatch pairs completely.
The issue i have found is that the scan time is so fast that the trigger never actually occurs because it cant unlatch itself quick enough before the next rung is latching it again.
That's a nonsense, the bit will NOT unlatch iteslf, It will only unlatch if the logic on the rung determines it should unlatch, and no amount of slowing things down will change that fact.
So the trigger never changes state essentially
Yes, it does, it changes state when the rungs are executed to change its state, no other time....
So if you could slow down the scan time you could actually get the trigger to move.
Not a chance, the "trigger" is being set and reset BY CODE, if the trigger is not ON when you want it to be, then your code is at fault, not the scan speed.