Hello everyone, I have a main routine where I use the XIC "Run" instruction. Below it, there is a JSR. Inside the logic of the subroutine, there is an OTL for "Run". In this setup, the "Run" instruction does not latch. However, when I move the JSR above the desired instruction, "Run" latches as expected. I believe the order in which the logic is executed is the reason for this behavior, but I am struggling to find a clear explanation. I tested removing a destructive OTE that comes after the subroutine, and the behavior aligned with my expectations. It seems that a destructive reference can overwrite the state of a bit until it is scanned again.
When the JSR is activated and Run=1, a rung that is logically false will reset the "Run" output to zero. This concept aligns with the idea in traditional ladder logic where the last examined condition takes precedence.
Ken Moore explained that when the JSR runs and the "Run" equals 1, a rung that is logically false will reset the "Run" output enable (OTE) to zero. This aligns with the principle in traditional ladder logic where the last examined condition takes precedence. It's common to encounter challenges with destructive bits, but it's usually a matter of overthinking the issue.
In PLC programming, timing is crucial, with the scan cycle acting as the clock that dictates the sequence of evaluating rungs and instructions. As Ken Moore advises, the last examined instruction "wins," emphasizing the importance of the timing of when actions are executed over what actions are performed. To ensure proper functionality, consider rearranging the order of instructions, such as moving the OTE before the OTL so that the OTL can dominate when its XIC condition is met. This adjustment can help prevent issues caused by conflicting instructions.
According to drbitboy, shifting the OTE before the OTL can lead to a successful outcome, especially when the XIC feed is True. In addition, after some experimentation, it was discovered that replacing the OTE with an OTL eliminates conflicts. It is advisable to keep latching outputs consistent to avoid any potential issues. Mixing and matching should be avoided to prevent conflicts from arising.
Patrickmoneyy shared his findings that switching from an Output Energize (OTE) to an Output Latch (OTL) does not cause conflicts. It is advised to keep latching outputs consistent to avoid potential issues. Understanding the functions of OTE, OTL, and Output Unlatch (OTU) in relation to scan process is crucial. An OTE writes both 1 and 0 to a tag address every scan based on the rung's true or false conditions. On the other hand, an OTL only writes a 1 when the rung is true, while an OTU only writes a 0 when the rung is true. While these instructions modify memory, using multiple OTLs and OTUs on the same address is common and does not trigger a duplicate warning. Each OTE instance should only appear once in the code. Combining OTEs with OTLs or OTUs is not recommended as it may lead to duplicate warnings. Remember, the scan process does not retain memory. Once a rung is evaluated and the appropriate value is written to the tag, it remains unchanged unless another destructive instruction writes to the same tag later in the scan. For example, if an OTE is true in rung 1 and false in rung 100, the tag will only be ON between rung 1 and 99. Similarly, an OTL or OTU will maintain the tag's state based on their conditions. By simplifying these instructions as writing 0 or 1 to a tag address, their functionality becomes easier to grasp.
You're right in your understanding that the order in which logic is executed in PLC programming, especially when using ladder logic, plays a significant role in the functioning of instructions. In your case, the JSR or Jump to Subroutine instruction executes the entire subroutine at that point in the scan cycle, hence affecting the state of the "Run" XIC instruction. Furthermore, if there's a destructive OTE afterwards in the main routine, this could indeed overwrite the state, because the output of the OTL (Output Latch) in your subroutine will be updated only at the end of the scan cycle. So if the scan hits the destructive OTE before it ends, it's likely to affect the latched output. To prevent such instances, ensure the latching and unlatching operations are in the correct order in your logic sequence and that no conflicting direct outputs (OTL or OTU) or destructive OTE instructions are occurring after a subroutine that could interfere with your desired outputs.
Definitely, it seems like you've answered your own question - the destructive OTE after your subroutine is indeed modifying the state of your "Run" bit. Remember that PLCs run top-to-bottom, left-to-right, so if a later rung acts on a bit modified earlier, the earlier rung won't see the change until the next scan cycle. It sounds like rearranging your logic so the OTL for "Run" comes after the OTE solves this issue, as the bit state isn't getting overwritten later. Understanding the sequential execution nature of PLC scans is crucial in avoiding issues like this.
I think you're on the right track with your understanding. In ladder logic, every rung is evaluated from left to right, top to bottom. So, the placement of your JSR does indeed matter. If the OTL instruction is placed after the JSR in the same rung, it won't operate until the next PLC cycle. This is happening because once the PLC executes the JSR, it jumps to the subroutine, executes it (which presumably sets the 'Run' bit), then jumps back and continues with the next instruction (the OTL), but by this time, your 'Run' bit is already set. On the other hand, when JSR is moved above, the 'Run' bit can be latched beforehand. Regarding the destructive OTE affecting the bit's state, yes, it can overwrite the status based on its logic, which might seem confusing if not carefully traced.
It sounds like you're encountering a common quirk in PLC logic execution. You're right that the order of execution plays a crucial role. When the JSR is executed before the "Run" instruction, it allows the logic within the subroutine to run first, which can set the "Run" bit before returning to the main routine. However, if "Run" is already being manipulated by the OTL, the main routine might overwrite that state when it processes the following OTE. Essentially, you're seeing the effect of scan time and how bits can be rapidly changed in different parts of your logic, which is definitely something to keep in mind when designing your routines!
It sounds like you're running into some interesting behavior with the scan cycle and how instructions are processed in your routine! You’re correct that the order of execution can greatly influence how bits like "Run" are latched. When the JSR is executed after the OTL, the system reads "Run" as off before the JSR has a chance to latch it, since the OTL is processed first in that scan cycle. By moving the JSR up, you’re ensuring that the “Run” bit is set before it can be overridden by any destructive instructions. It can definitely be tricky to manage these interactions, but understanding the scan order really helps clarify these nuances!
It sounds like you're running into some interesting behavior with the timing and execution order of your logic! You're correct that the order of instructions can significantly impact how bits are latched and overwritten. When the JSR is placed after the "Run" instruction, the OTL (Output Latch) in your subroutine is likely executing before the main routine has a chance to update the state of "Run," which causes it to behave unexpectedly. By placing the JSR above the "Run" instruction, the scan cycle processes the latch command first, allowing it to maintain the proper state. It's also a great catch regarding the destructive OTE, as it emphasizes how crucial the order of operations is in ladder logic programming. Always best to keep those scan sequences in mind!
âś… Work Order Management
âś… Asset Tracking
âś… Preventive Maintenance
âś… Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - The XIC "Run" instruction may not latch as expected in a PLC subroutine execution setup due to the order in which the logic is executed. Moving the JSR above the desired instruction can cause the "Run" instruction to latch as intended.
Answer: - The order of logic execution can significantly impact the behavior of PLC instructions. In the provided scenario, the placement of the JSR instruction before the desired logic can affect whether the "Run" instruction latches or not.
Answer: - A destructive OTE that comes after the subroutine can overwrite the state of a bit until it is scanned again, potentially affecting the behavior of instructions like XIC "Run" within the PLC subroutine.
Answer: - To ensure consistent behavior of the XIC "Run" instruction in your PLC program, consider carefully managing the order of logic execution, avoiding destructive references that may interfere with instruction states, and testing different configurations to align the behavior with your expectations.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.