In my program, I am utilizing a SystemTimer with a capacity of one ton, which I adjust based on different conditions. I am in the process of migrating an IDEC ladder to work with an AB PLC. The IDEC ladder utilized a singular global timer that would reset in a similar manner. As the program transitions to various phases of the process, it will update the timer's preset value and activate it under new conditions, causing it to reset. The problem arises when the timer reaches its preset value, triggering the DN bit, but continues to remain enabled. Upon investigating the cross references for SystemTimer.EN, I identified a specific rung that was causing this issue. Despite this rung not being true, it was still enabling the timer. By replacing the SolenoidRetract XIC and Autoswitch1Bottom XIC with a toggleable bit, I was able to successfully reset the timer by setting SystemTimer.EN to false. Are there any hidden factors at play here? Could there be an unseen trigger causing the timer to remain active despite the lack of indication in the cross references? Thank you, Michael.
When utilizing the TON instruction with the same Timer address in multiple sections, the EN bit will be set if any preceding rungs have a "rung-in-true" condition. It is advisable to use only one TON instruction for the timer as long as it is continuously scanned, and employ the RES (reset) instruction to reset it after loading a new preset. Make sure not to keep the RES instruction true as it will prevent the timer from functioning properly. To manage different conditions for operating the timer in various functions, it is recommended to OTE different bits based on the conditions for each machine state, and then place those bits on parallel branches to enable a single instance of the TON. Be cautious of avoiding overlaps where multiple sets of conditions remain true unintentionally. It is easier to identify such issues if all branches are on a single TON rung. This scenario involves machinery control with conditional subroutines, which may seem ideal for a computer programmer but can be challenging for a PLC technician in practice. When a condition routine is stopped using an OTE instruction, its address remains unchanged. Similarly, a TON instruction stops being evaluated but the enabled or done bits will still be set until another destructive instruction affecting that element is encountered by the PLC. Conditional subroutines in ladder logic should be primarily used for data handling rather than machinery control. It is essential to carefully consider the application to ensure optimal PLC operation.
One issue that stands out is the repeated use of the timer tag in 7 TON instructions. This can lead to confusion and inefficiencies in programming.
I realize that using the same timer tag in 7 different places may not be the most optimal design choice, but I was advised to replicate the IDEC code as closely as possible. Upon further investigation into how the timer is activated, I discovered that a unique bit was added to a branch near each set of instructions for enabling the SystemTimer. Despite SolenoidRetract being false, indicating that the rung should not evaluate as true for the timer or retractTimer bit, I wanted to pinpoint where the timer was actually being enabled.
Upon examining the cross references for "retractTimer," it appears that the only instance of it being written to is on this particular rung.
It appears that a conditional routine has ceased being scanned, leading to the current state where the SolenoidRetract bit is not being updated. Your programming software continues to update the states of addresses, indicating that your new test bit is true. However, since the PLC is no longer instructed to act on the test bit, it retains its last known state (on).
Hi Michael, from what you've described, it seems you've done a thorough job troubleshooting. It's noteworthy, though, that PLC timers can sometimes act unpredictably due to certain 'latched' conditions - some software inadvertently create 'memory' within the PLC that can cause the timer to continue operating even after you've logically instructed it to stop. You might consider adding a brief 'unconditional stop' to your program logic upon the initiation of each process cycle, just to make sure this isn't happening. If this doesn't solve the issue, perhaps the timer’s preset value isn’t adequately resetting. Best of luck with your migration!
Hi Michael, it sounds like you've done a comprehensive check for the possible causes. In my experience, "ghost" triggers for timers are usually due to an errant rung elsewhere in the program, or a conflicting variable. You might want to double check not just the cross references for SystemTimer.EN, but also for SystemTimer.DN in case there’s a hidden interaction there. Remember, in ladder logic, runtime order can sometimes cause strange things to happen. Also ensure the transition to AB PLC didn't introduce any inadvertent changes. It's worth rigorously testing your system using different scenarios to uncover any hidden behavior. Good luck!
Hey Michael, this sounds like a complex issue but you're on the right track. AB PLC timers can behave a bit unexpectedly if you're used to IDEC. From what you've described, it seems like there might be a latching mechanism keeping the timer enabled despite your logic instruction. Consider carefully revising your latching/unlatching logic or seek a possible buried code that can affect the SystemTimer.EN status. If all else fails, double-checking timer instances and addressing could help - maybe there's an accidental overlap. Good luck and hang in there!
Hi Michael, it's intriguing how deceivingly intricate PLC programming can be at times. While you've done an excellent job identifying a potential issue with the rung enabling the timer, the SystemTimer existing outside the ladder could throw a loop. If the SystemTimer's preset is being updated elsewhere in the program, it could be continuously re-enabling itself. This could be a result of signal feedback, where some code references may be missed in the cross-reference table. I would suggest double-checking all references to SystemTimer, including conditions that may indirectly affect it.
Hi Michael, it sounds like you've been digging into a tricky issue! One possibility you might want to consider is whether there are any unintended interactions between the logic of your rungs. Sometimes, indirect references or conditions in other parts of the program can sneak in and affect the timer's behavior, especially if they manipulate shared variables or bits. It could also help to double-check that there aren't any duplicate tags or logic sequences that might be enabling the timer, or even an unintentional latch that's holding the enable bit true. Making your logic more modular with clear state transitions might also shed some light on what's happening. Good luck with the transition!
Hi Michael, it sounds like you’ve made some great progress on your transition! One thing to consider is whether there might be another part of your logic or a condition in your program that might be inadvertently keeping the SystemTimer.EN enabled even when you think it shouldn't be. Sometimes, nested conditions or overlapping rungs can create behaviors that aren’t immediately obvious. It might help to take a closer look at any indirect references or any flags that might influence the timer state. Also, ensuring that all possible conditions to disable the timer are exhaustively accounted for can help prevent any hidden triggers from activating. Good luck with the migration!
✅ 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: Answer: One possible cause could be a rung in the ladder logic that is incorrectly enabling the timer even when it should not be. It's important to carefully review the logic and cross-references to identify any unintended activation conditions.
Answer: Answer: To troubleshoot a TON timer activation problem, start by examining the ladder logic and cross-references related to the timer's enable bit. Look for any conditions or rungs that might be inadvertently keeping the timer enabled, even when it should be reset.
Answer: Answer: Yes, there could be hidden factors contributing to a TON timer remaining enabled, such as unexpected logic conditions, incorrect rung configurations, or overlooked triggers. Careful inspection of the ladder logic and cross-references can help identify and address these hidden factors.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.