I'm currently editing a program retrieved from a functioning machine, and I've come across several warnings, specifically "Shorted Branch Detected." As someone who is relatively new to the Allen-Bradley 5000 series but has extensive experience with the 500 series, I'm curious about how to address these warnings. In the 500 series, I would typically create an "Always False Input" to bypass such issues for successful verification. Additionally, I'm noticing warnings for "Duplicate Destructive Bit Reference Detected." I reached out to the original equipment manufacturer (OEM) for clarification but didn't receive a satisfactory response. Is this something I should be concerned about? At least there are no errors when I verify the project. I’m just trying to understand if these warnings indicate a deeper issue.
The alert "Duplicate Destructive Bit Reference Detected" is certainly concerning. However, if the original equipment manufacturer (OEM) remains responsible for the machine's operation, your options may be limited. I typically refrain from delivering any code that triggers such warnings, as most of my clients also prefer to avoid them.
The "shorted branch" refers precisely to its name; it serves as an alert to inform you of its presence in your programming code. Regarding "Duplicate Destructive Bits," it is important to understand that during Machine State programming, scanning the entirety of your program is not always required. Many programmers opt for Output Energizing (OTE) instructions to activate devices instead of utilizing Latch and Unlatch commands. This approach may lead to issues with duplicate bits. As a result, you might find two OTEs assigned to a single bit, but only one will be effectively executed in the program flow due to the specific conditions set in the Jump to Subroutine (JSR) instructions associated with them.
In my experience, I have observed instances where shorted branches and destructive bits are identified due to the OEM's testing protocols utilized during the equipment's manufacturing and startup processes. These routines simulate operational conditions effectively. However, a significant oversight occurs when the testing routines are discontinued after initial checks, leaving the test code embedded within the PLC. Additionally, I've encountered situations where the code is structured to accommodate future enhancements. In these cases, if new features are integrated post-startup, the necessary code is already present and simply requires activation, or adjustments to remove any shorted branches. It’s essential to thoroughly investigate these routines to understand their functionality and implications. – Kevin
Thank you, everyone! I believe that’s exactly what it is. I implemented a brief routine in the application and found myself scrolling through all the elements while double-checking my work, which piqued my curiosity.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.