The line between genius and bat-***** insane is a thin one, and I'm not sure which side of the line this technique sits on. One half of me goes "oh my god, that's not how you do things! Why would you abuse ladder logic like that!", and the other half of me goes "actually, that's quite a clever way of doing it, even if it IS unconventional".
To take just the first rung, and ignore all questions about why your enable/disable states are not directly related to each other:
If the operator presses the HMI "enable" button, the first thing that will happen is that the button will be unlatched, or "turned off", but the HMI. This is good practice for a number of reasons, which you can find me raving about in plenty of other threads if you actually care.
If the roaster at this stage is NOT enabled, then three things will happen upon execution of the first branch:
1. The BOOL tag Roaster05.Enabled is false, so the XIO sets it's rung-out condition to true
2. The rung-in condition to the ONS is true, and it's memory bit (BOOL tag Roaster05.ONS.0) is 0. The ONS instruction examines its rung-in condition, and its memory tag. If the rung-in condition is TRUE, and the memory tag is FALSE, it will set it's rung-out condition to TRUE and it's memory bit to 1. In all other cases, the rung-out condition is FALSE. So in this instance, the ONS instruction will set its rung-out condition to TRUE, and it's memory bit to 1
3. The OTL instruction will set the BOOL tag Roaster05.Enabled to 1, since the rung-out condition from the ONS was TRUE
Now, the PLC will execute the second branch...
1. The BOOL tag Roaster05.Enabled now has a value of 1 (set by the OTL on the previous branch, so the XIC instruction will set its rung-out condition to TRUE
2. Roaster05.ONS.0 was set to 1 by the ONS on the previous branch. This means that, although the rung-in condition to the ONS is true, the memory bit is already a 1. So in
this case, the ONS instruction will set it's rung out condition to FALSE.
3. The rung-in condition to the OTU is false, so the OTU will do nothing
Hey presto, you have toggled your bit from OFF to ON!
Now, let's imagine the scenario if the roaster IS enabled when the button is pressed.
First Branch:
1. Roaster is enabled, so the XIO instruction sets its rung-out condition to FALSE
2. Rung-In condition to the ONS is false, so it sets it's memory bit (Roaster05.ONS.0) to zero (even though it probably was already) and it's rung-out condition to false
3. Rung-in condition to the OTL is false, so it does nothing
Second branch
1. Roaster is enabled, so the XIC instruction sets its rung-out condition to true
2. Rung-in condition to the ONS is true, and the previous branch set its memory bit to 0, so the ONS sets its memory bit to 1 and it's rung-out condition to true
3. Rung-in condition to the OTU is true, so the OTU sets the Roaster05.Enabled BOOL to zero
Hey presto, you have toggled your bit from ON to OFF!
This is one of the reasons I prefer AB over Siemens. A Siemens PLC would take one look at this logic and tell you four different ways to f*** off (at least three of them in German). But in AB world, you can do things like this - it's absolutely not how the instruction was intended to be used, but as we can see above, it works perfectly, and in reality, it's actually quite simple and efficient.
The only question that remains is "given the target audience of this code, is doing a trick like this a good idea?"
But that is a whole 'nother discussion that I don't think we need to have
again