Check out the code provided below. Hello everyone! This project marks my inaugural endeavor utilizing a Rockwell PLC, as I have predominantly worked with Unity Pro over the past 15 years. The objective at hand involves remapping approximately 40 analog values. Throughout the process, I incorporate the value itself, a signal quality bit (which displays #BAD on the HMI when the quality bit is inactive), and a signal fail that triggers an alarm. By toggling the internal SIM_ON (Simulator On) bit, the system is reset, all alarms are cleared, and the PLC is primed for testing/FAT using other SIM values. In my experience with a Schneider PLC, I utilized a block that is disabled when SIM_ON is true, allowing me to control individual outputs for testing purposes without requiring duplicate tags. However, I have discovered that I cannot individually test the _QUAL and _F bits apart from the local .Fault, which is impractical. This is crucial in verifying that the correct tags are displayed in the HMI/SCADA system. Upon deactivating SIM_ON, all alarms/statuses are triggered simultaneously, rendering the test ineffective. Currently, my only viable solution seems to be duplicating the SIM tags, a task I aim to avoid as I prefer streamlining features before presenting to the customer. This not only consumes excess space but also adds unnecessary workload. I welcome your insights on this matter. I am certain that others have encountered similar challenges. In essence, how would you handle this situation? Thank you.
I'm uncertain of how this directly pertains to your specific project. In our approach, we utilize dedicated IO mapping routines for each analog or digital module. These routines are responsible for mapping module points and status data to the relevant tags used throughout the program. Additionally, scaling and filtering of analog data is conducted within these routines. On a system with approximately 50 Flex & Point racks, we opt to create a separate routine for each rack rather than each module. There are occasional deviations from a strict 1:1 mapping, such as implementing a run reverse tag alongside a run tag for hardwired drive control scenarios requiring two outputs for reverse operations. Using the SIM_ON function would primarily involve deactivating the Jump to Subroutine (JSR) related to the module mapping routine and activating a JSR to a distinct routine where simulated values are linked to the program tags. This new routine would also include any necessary logic for automating the adjustment of test values. Naturally, there may be exceptions to this process as needed for specific cases.
5618 mentioned that activating SIM_ON would simply disable the JSR to the module mapping routine. This concept is similar to the "block that [they] disable when SIM_ON" value is set to 1 in Unity Pro. Explore further details by clicking here.
Wow, this is truly amazing. Thank you all so much!
Dalporto noted that with their current setup, they have discovered limitations in individually testing the _QUAL and _F bits, except for the local .Fault which is not very helpful. This is crucial for ensuring the correct tag placement on the HMI/SCADA system. When SIM_ON is turned off, all alarms and statuses come in simultaneously, rendering them ineffective. It is worth mentioning that you can disable the module in the Hardware tree and manipulate the .Fault and .Data variables as needed. While this process can be tedious with multiple modules, it allows for operation without the SIM bit. Attempts to programmatically list and inhibit modules in the past have been unsuccessful.
cardosocea mentioned the option to disable modules in the Hardware tree and manipulate the .Fault and .Data variables as needed. While it can be tedious with a large number of modules, this approach allows for flexibility without the SIM bit. In my experience with Logix 5000, I inhibit modules and create a simulation program to interact with input tags via outputs. Although automating the process of listing and inhibiting modules may be challenging, SSV instructions can be utilized to easily inhibit or un-inhibit modules.
Great to hear about your transition to Rockwell PLC! I've faced similar issues before when testing individual bits. One viable workaround I found involved incorporating a JSR Instruction that points to a testing routine when the SIM_ON bit is true. This routine essentially mimics the function of your analog inputs. You create test bits (instead of duplicating SIM Tags), which provide a level of flexibility when testing _QUAL and _F bits independently. Remember to revert the JSR Instruction back to normal routine when you turn off the SIM_ON bit, ensuring that everything returns to normal operation when not in testing mode. As always, carefully test this method before implementing to avoid any unwanted outcomes. A well-architected design can eliminate unnecessary memory usage and assures the implementation process stays clean and manageable. Hope this helps.
It sounds like you're navigating quite the transition with your first Rockwell PLC project! Have you considered setting up a dedicated test mode within your code that allows you to simulate the _QUAL and _F bits independently without duplicating tags? This could involve creating a temporary simulation function or using a case structure to switch between normal and test operations, allowing you to manipulate those bits as needed for your HMI/SCADA checks. It could save you from the hassle of duplicating everything while keeping your system neat for customer presentation. Just a thought! Good luck!
✅ 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: The main challenge faced when testing a Rockwell PLC in this scenario is the inability to individually test the _QUAL and _F bits apart from the local .Fault, which is crucial for verifying the correct tags displayed in the HMI/SCADA system.
Answer: Answer: Toggling the internal SIM_ON bit resets the system, clears all alarms, and primes the PLC for testing/FAT using other SIM values. However, deactivating SIM_ON triggers all alarms/statuses simultaneously, rendering the test ineffective.
Answer: Answer: One alternative solution being considered is duplicating the SIM tags to control individual outputs for testing purposes. However, this approach is seen as consuming excess space and adding unnecessary workload, which the user aims to avoid.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.