I have developed a Panelview display showcasing my 1734-IB8S cards, indicating the status of Inputs (on/off) and any past faults on the card or IO channels. The LED colors on the Panelview are white for OFF, green for ON, and red for faults. Pressing the reset button clears the red fault indicator. Initially, I used a labor-intensive method with 16 rungs per IO Card in the safety program. To streamline this process, I created an AOI where entering the 1734 card tag generates the necessary DINT. Although successful offline, I encountered a roadblock during real-time operation due to the "Instruction not certified for use in Safety routines" message. It seems that AB does not allow AOIs to be utilized in safety routines. Any suggestions on alternative methods to avoid the manual approach? - Attempting the standard program was unsuccessful due to safety scope restrictions, preventing reference to the safety card. - I am unable to transfer data from the Input Card Data Tag to a usable format like DINT or Array. - While mapping Standard tags to Safety tags is feasible, the reverse is not possible, limiting monitoring of safety tags in the standard program. Any insights or solutions to overcome this challenge are greatly appreciated.
Kekrahulik stated that the code for the safety program revolves around Safety Card Inputs. While conventional logic may check safety inputs effectively, it cannot be used to regulate safety outputs. This demonstrates the importance of implementing specialized safety procedures to ensure proper control and monitoring.
plvlce mentioned that while regular logic can handle safety inputs effectively, it cannot be used to control safety outputs. It is important to find a way to reference the Data Type AB:1734_IB8S_Safety2:I:0 for use within an AOI or to copy it to a separate tag that can be utilized in an AOI. When creating an AOI, note that the Datatype can only be an InOut parameter and cannot be used as an Input. This limitation also applies to using it in a standard program. If you encounter issues with this, consider seeking alternative solutions for your programming needs.
When creating an Add-On Instruction (AOI) in Logix, you may encounter limitations when trying to reference a specific Data Type like AB:1734_IB8S_Safety2:I:0. While AOIs typically only allow this Data Type to be used as an InOut parameter, there is a workaround that involves copying the data to a separate tag within the AOI. It's possible that the restriction on using the Data Type as an Input parameter could be related to the module tags being forced to be InOut. One solution could be to use a COP instruction to buffer the data into the AOI. For example, you could use "COP Safety2:1:I TestDint 1" in an offline program with 1734-IB8S modules to verify compatibility without errors. If you want to retain the original bit names, creating a User Defined Type (UDT) and copying the data into that structure could be a useful approach. This method ensures that your inputs are effectively buffered within the AOI for seamless integration into your programming logic.
I attempted to use a Copy (COP) function to transfer data, but encountered an issue where my card inputs were not all transferring correctly. Despite having all statuses true, only bit 0 of my TestDint was being successfully copied. I experimented with different copy lengths, but the issue persisted.
I am impressed by the methodology employed by the experts at Rockwell Automation in utilizing Module types to access module state and memory-mapped variables. Although I am unsure of the process myself, I believe that it may be achievable through the use of CIP wizardry.
It appears as though you've run into a pretty common problem dealing with safety-rated hardware. The safety program has a stricter scope restriction for protective purposes, which is why you're having a tough time. One possible solution is to use a GSV (Get System Value) instruction to retrieve the fault codes from the safety card. However, please note GSV is a fairly advanced instruction which might need time to master. Also, on the subject of displaying fault indicators on the PanelView, you could use 'Fault Routine' in the safety programming to lock a non-safety tag bit when a fault occurs. Then, from your standard program, you can reference this bit to trigger the fault display on the PanelView. In essence, the Fault Routine can act as a part-time bridge between your safety and standard programs. Hope this helps!
It sounds like a really complex and frustrating situation. Have you considered using gateway tags? These tags can be used in the safety code and referenced in the standard code. This way, you can link your Panelview display to the standard tags and these tags in turn, can serve as "go-betweens" for the standard and safety programs. As such, this approach might bypass the restrictions on referencing safety tags in the standard program. You will need to ensure these gateway tags are updated whenever the IO input status changes. Remember to keep redundancy checks in place to ensure safe operation.
It seems like you’ve really been doing your homework on this issue and I empathize with your situation. I've encountered similar roadblocks when working with safety modules. It’s true that transferring data to a usable format like DINT or Array is difficult due to certain safety considerations. Here's an idea that worked in my situation - Have you tried setting up a Diagnostic Object configured with the same tag as the Safety Point IO? Then, use a non-safety routine to handle it. This workaround can allow copying the safety data to the standard scope without triggering the safety violation. This way you can monitor safety tags in the standard program. Be careful to ensure that the diagnostic object and handling routine do not influence the safety of the machine, though.
It sounds like you've done a great job so far with your Panelview display and the organization behind it! Given the restrictions you're facing with AOIs in safety routines, one option to consider is using a function block, which might be more compliant with safety requirements. You could create a simple Function Block that handles the logic for monitoring the inputs and faults without using an AOI. Additionally, you could set up a custom data structure to simplify the handling of those inputs and faults. It might also be worth diving into your documentation for the specific capabilities of your safety controller, as sometimes there are underlying features or memory addressing options that can help you work around limitations in a creative way. 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: Pressing the reset button on the Panelview display can clear the red fault indicator for the 1734-IB8S Input Cards.
Answer: Answer: The "Instruction not certified for use in Safety routines" message suggests that AB does not allow the use of AOIs in safety routines. This limitation may require alternative methods to avoid a manual approach for programming.
Answer: Answer: If you are facing challenges transferring data formats, consider exploring alternative methods or tools within your programming environment to achieve the desired data conversion.
Answer: Answer: While mapping Standard tags to Safety tags is feasible, the reverse process may not be possible, limiting the ability to monitor safety tags within the standard program. Consider evaluating workarounds or modifications to address this limitation.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.