Hello, I am currently reviewing some legacy code and would appreciate an expert's validation of my findings. Upon analysis, I have discovered the following: 1. The B64:22/3 instruction will remain latched and never release. 2. The T75:77 timer will remain set and not reset. 3. The operation T75:77.TT is equivalent to T75:77.EN AND negate(T75:77.DN). This simplifies to T75:77.TT AND T75:77.TT, which aligns with the boolean identity A + A = A. Upon further investigation, I noted that there is no indication of B64:22/3 being written to in any other part of the code, such as BTW, COPY, or MOV instructions. Despite this, I cannot comprehend the rationale behind writing the code in such a manner. It appears as though the intention was to ensure the completion of timer T75:90.
When reaching an agreement, it is important to ensure that there are no Human-Machine Interface (HMI) or other external devices that can manipulate the value of B64:22/32 to zero. However, there may be a disagreement if the T75:77 value is reset between rungs 8 and 10 when the I:021/0 value is 13. It is crucial to note that T75:90 on rung 11 will be reset just before reaching its expiration due to a reset in T75:77/TT value on the scan cycle. This adjustment ensures that T75:90 does not expire prematurely.
Looking for a way to set WORD B64:22 to zero? This process will help you clear all bits in the WORD.
Ken Moore is inquiring about a way to set all bits in the WORD B64:22 to zero. This can be achieved by referencing MOV or mathematical instructions and COP instructions that manipulate B64:x, with x being less than or equal to 22. For more details on this topic, scroll up in the x-ref section and search for relevant instructions.
1. It is highly likely that data is being written to B64:22 as all the bits in that word are being latched, indicating a need for something to reset them. Without a reset mechanism, the bits would remain on indefinitely, even after a power cycle. Take Joseph's advice and check the cross-reference for a command using the full word, as CLR or MOV commands cannot reset individual bits. Instead, consider using unlatches for individual bits or a COP or FLL to reset multiple words. 2. By resolving the issue mentioned in question 1, you will understand how the timer is reset. Despite the screenshot showing no visible logic to reset the timer, it does reset during a power cycle or when the controller transitions from Program to Run mode. Keep in mind that TON instructions reset during these transitions, while latches and RTO timers do not. 3. The /DN and /DN inputs on rung 11 are redundant with the /TT. Simplify the logic by using only the /TT input here.
When analyzing the screenshot, Operaghost stated that the timer visible in the logic will not reset. However, I disagree. By pressing down on I:021/0, the discrete input value will reset T75:77 on Rung 8 each scan cycle. Once I:021/0 has been continuously valued at 1 for 40cs after a download, B64:22/3 will be latched to 1 on Rung 9, causing T75:77/EN to always be 1 after Rung 10 evaluation. The behavior of T75:77 is dependent on the input I:021/0, continuously resetting on each evaluation of Rung 8 and restarting on each evaluation of Rung 10. As long as I:021/0 remains at 1, the value of T75:77/TT will stay at 1 until the next scan cycle when the reset will clear it back to 0. T75:77 will not expire as it is constantly reset by I:021/0. T75:77 constantly restarting enables T75:90 to expire, unlike T75:77, which resets each cycle. Changes happen when I:021/0 transitions from 0 to 1; T75:77 resets/start cycle each scan cycle as long as I:021/0=1, and T75:90 times out 1s later. T75:90 remains in its expired state until 1s after I:021/0 goes back to 0. This pattern repeats with each transition of I:021/0 value, effectively mimicking its behavior with a 1s delay in T75:90/DN.
It sounds like you've made a meticulous review of this existing code. Based on your findings, there might indeed be some lingering issues - particularly with the B64:22/3 instruction and T75:77 timer. You're correct in pointing out that without clear instructions actively resetting or writing to these parts of the code, they will likely continue to hold their state. As for T75:77.TT, you've accurately recognized the logic simplification, matching the Boolean Identity law. As to why it was written this way, it can be hard to say without understanding the original context or design intentions. Code like this can sometimes be the result of patches or changes made over time that unintentionally create these issues. Remember, there's always a balance to be struck between perfectly clean code and practical working solutions depending on time-frame, use-case and resources.
From your observations, it does sound like the legacy code you're working with was written with some unusual and perhaps redundant aspects. Also, your findings on T75:77.EN and negate(T75:77.DN) simplifying to T75:77.TT is spot-on based on Boolean algebra. As for B64:22/3 staying latched and not being influenced by anything else, it could just represent stated conditions that were vital during the original conception of the code. However, the lack of reset for T75:77 timer seems atypical. The idea might have been to keep the timer perpetually active, ensuring the operation related to this timer is always ready to execute. Despite the potential redundancies and quirks, legacy code usually reveals the type of constraints and thinking of the original developerswhich can be fascinating.
It sounds like you've done some thorough analysis of the legacy code! The fact that B64:22/3 remains latched without any other write operations suggests it might have been intended as a permanent state flag, potentially to trigger other logic or safety conditions later on. As for the T75:77 timer, it’s interesting how the logic seems simplified, but if it doesn’t reset, it could lead to unexpected behavior down the line if not adequately managed. It’s definitely worth considering if the original developer had a specific application in mind that just didn’t translate well into the current implementation or if they were just taking an unconventional approach to structure the timing logic. Have you thought about reaching out to others who might have worked on or maintained the system for more context? Their insights could be invaluable!
It sounds like you've done a thorough job analyzing the legacy code! The behavior of B64:22/3 staying latched and T75:77 remaining set certainly raises red flags, especially with the lack of write instructions for B64:22/3. It seems like the original developer may have had a specific use case in mind, possibly to ensure that certain conditions were met before T75:90 could complete its cycle. However, this kind of coding can lead to confusion and unintended consequences down the line. Have you considered documenting these findings and reaching out to the team’s historical context—there might be insights into the original design choices that explain this unusual setup.
✅ 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 B64:22/3 instruction remains latched and never releases because there is no indication of it being written to in any other part of the code, such as BTW, COPY, or MOV instructions.
Answer: - The T75:77 timer remains set and does not reset due to the code logic and the absence of reset instructions associated with it.
Answer: - The operation T75:77.TT = T75:77.EN AND negate(T75:77.DN) simplifies to T75:77.TT AND T75:77.TT, which aligns with the boolean identity A + A = A.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.