New ✨ Introducing Oxmaint Asset Hub for Machine Builders and OEMs. Explore Now

Q&A Community

How to Detect Communication Faults between 1794 AENT Remote Module and 1756-L55 Processor Without Controller Malfunction

Question:

I am seeking a solution for identifying communication faults between a 1794 AENT remote module and a 1756-L55 Processor without causing a controller malfunction. I am looking for a method to implement a safety measure to detect and disable all related outputs in case of a fault. Are there any status bits available from the module that can be utilized to establish a watchdog system for this purpose?

Top Replies

To retrieve system information, consider utilizing the Get System Value (GSV) instruction. By adding this instruction to a rung and pressing F1 for detailed assistance, you can easily access the information you need. Another option is to search for the relevant information on this platform. Happy programming!

Explore Chapter 1 of the 1756-PM015 user manual from Rockwell Automation, available for download as a PDF document. Dive into pages 14-15 for detailed information on how to optimize the performance of your machinery.

Utilize a GSV Instance Name to retrieve the AENT Attribute Name, which is the EntryStatusDest tag (int). Verify if the Destination tag matches 16384 (4000 hex) to ensure smooth communication with the device; any other outcome indicates a communication fault that requires action. This method is applicable for configuring all Ethernet-enabled devices in RSlogix, such as drives, HMIs, and 1756-ENxT modules. Implement a sequencer for checking multiple devices efficiently, or set conditions to only verify LedStatus of the main processor if it does not equal 3 (GSV, Class name = MODULE, Attribute Name = LedStatus).

Both Mark and bimini3 have suggested a universal method for checking the status of a Module Object. The "Logix 5000 Controllers Information and Status" Programming Manual (1756-PM015) is a comprehensive guide that is essential for detailed programming in ControlLogix systems. A simple way to determine the connection status of a FLEX or POINT adapter with a Rack Optimized connection is to look for the automatically generated tag for a 1794 adapter on ControlNet or EtherNet/IP. The tag, AdapterName:I.SlotStatusBits, provides 1 bit per slot for monitoring the status of modules in the Rack Optimized connection. If the connection to the adapter is lost, all bits will turn true, resulting in the DINT tag value becoming -1.

For more detailed information on the manual mentioned by Ken, please follow this link: http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm015-en-p.pdf.

More Replies

Concerned about how output modules react when communication is lost? You have the ability to customize the behavior of your Flex I/O output cards in such situations. This functionality is also found in 1734 Point I/O modules, indicating it may be a common feature across all AB output modules.

I'm inquiring about how to check the communication status of the 1794-AENT Flex module with a 1769-L32E CompactLogix controller. In case of communication loss with the 1794-AENT, I need to be able to monitor this status. Which specific bit should I use to read the communication status of the 1794-AENT Flex module? Any guidance on this matter would be greatly appreciated.

@Ones_Zeros - Have you taken the time to read any of the responses regarding this particular topic?

User Ones_Zeros asked for guidance on how to check the communication status of the 1794-AENT Flex module with a 1769-L32E compact Logix controller. In the event of communication loss with the 1794-AENT, they wanted to be able to detect it. To monitor the communication status, it is recommended to use the GSV entrystatus and compare it as detailed in previous responses. Thank you for your assistance.

Great, thank you!

Robertmee provided some guidance on how to check the status bit using the GSV entrystatus. In addition, it's important to note that for some devices, the status bit may not update immediately when communication is lost, only updating once communication is restored.

To effectively monitor the network connection between two devices, it appears that utilizing the GSV statement is necessary. However, as a beginner in this area and finding the help files lacking, I am seeking guidance from experienced individuals who can provide a clearer explanation. I am unsure about how to configure the settings, including the Class Name (which may refer to the Flex 1794-AENT module to be monitored), Instance Name, Attribute Name, and Dest. Any assistance on this matter would be greatly valued.

To ensure the status of your device's communication, use the ModuleInstance Name as indicated in the I/O tree. Create an Attribute Name called EntryStatusDest, which should be a DINT tag that you define. After setting up this instruction, divide the EntryStatus by 4096 into another DINT tag that you establish. Compare this new tag to a value of 4 - if it matches, your communication is functioning correctly. If not, it indicates a communication issue. For optimal efficiency, consider implementing a timer for your GSV calls. Set a specific interval, like every second or a few seconds, to check for faults. Calling GSV unnecessarily every scan can consume system resources. This may not be a concern if you have only one GSV call and one ethernet device. However, if you are monitoring multiple devices, the cumulative impact on system performance can be significant.

Thank you so much for your help in configuring this. I truly appreciate it!

A crucial query remains: can the final DINT tag value be easily retrieved in Wonderware? As previously mentioned, if the value is 4, the connection is deemed reliable; any different value indicates otherwise. Would it be necessary to employ a compare instruction in the PLC to match this value of 4 and control a coil's activation in order to transmit the data to Wonderware? In this scenario, "ON" signifies a good connection, while "Off" indicates disconnection.

When reading the final DINT tag value in Wonderware, it is important to ensure a proper connection. Using a compare instruction in the PLC to check if the value is 4 can help in activating a coil on/off, while also displaying the value in Wonderware. By setting up an alarm bit in the PLC/Wonderware, you can monitor the status of the connection. Wonderware has a built-in alarm service for discrete values, allowing you to easily track any changes. Additionally, you can customize the alarm visualization in Wonderware by animating the DINT value from the PLC. However, utilizing analog tags with Hi/Lo alarm limits may add complexity to the setup.

@Ones_Zeros, have you taken the time to read the responses on this subject? It's true, but there's no need to behave in such a manner. Remember to always keep an open mind and consider different perspectives.

Ken Roach shared a method to quickly detect the connection status of a FLEX or POINT adapter with a Rack Optimized connection. When using a 1794 adapter on ControlNet or EtherNet/IP, a tag is automatically generated providing 1 bit per slot for the status of modules in the Rack Optimized connection. If connection to the adapter is lost, all bits in the tag become true, resulting in the DINT tag value being -1. It's always valuable to learn something new, especially from experts like Ken. In our experience, connecting the 24V supply to one of our 24V inputs and the 120V supply to one of our 120V inputs in a rack often leads to faults such as "24V absence" and "120V absence," indicating a fault in the rack. This can be attributed to issues with the 1794-AENT module when separately energized analog or specialty modules do not power up simultaneously. Additionally, there was a situation where a user Ones_Zero successfully revived a 5-year-old thread by following Ken's advice. However, there was confusion as to why the thread was resurrected a year later.

In cases of communication loss, it is crucial to configure your Flex I/O output cards to ensure proper behavior. This also applies to 1734 Point I/O modules and likely all AB output modules. Resetting outputs is the only solution when communication is lost, as the processor is unable to do so.

Although this discussion is dated, it is worth noting that there were reported problems with earlier versions of the 1734 AENT firmware, resulting in packet drops and communication faults. It is advisable to review the firmware history and any known anomalies and corrections to see if this issue also affects the 1794 AENT.

Have concerns about output module behavior during communication loss? You can customize your Flex I/O output cards to respond a certain way in such scenarios. This feature is likely available for all AB output modules, including the 1734 Point I/O. Additionally, I am inquiring about adjusting the properties of the 1794 module. Can the range be modified on the screen? I am utilizing the studio with 1756 and 1794 cards in the controller tags. Is the only option for adjusting the output scale in the tags section?

Thank you for joining the PLCTalk Forum community! This post is part of an older discussion loosely related to the topic at hand. To contribute, head back to the Q&A section and click the "Start a New Thread" button in the upper left corner. Be sure to mention your Studio 5000 version and provide details on the specific FLEX I/O modules you are setting up. Your input will help fellow members troubleshoot effectively.

In the realm of industrial automation, it is crucial to ensure the seamless connection status of FLEX or POINT adapters, specifically those equipped with a Rack Optimized connection. By leveraging a 1794 adapter on ControlNet or EtherNet/IP, a generated tag provides essential insight into the status of connected modules. In situations where the connection is disrupted, a simple yet effective method involves monitoring the status bits within the tag. For instance, with four 1794-AENTR remote racks housing various modules, the detection of power issues or communication obstacles can be streamlined. By analyzing the changes in specific address bits when modules are powered down, a clearer picture of the system's functionality emerges. Utilizing this data, a strategic approach involving a GRT 0 comparison can be implemented to promptly identify and address any connection faults across the remote racks. This method has proven to be reliable in ensuring optimal system performance and minimizing downtime.

Thank you for your input! It is logical that only the initial 8 bits of a traditional 1794 FLEX adapter object are utilized, as FLEX is designed to accommodate a maximum assembly of 8 modules.

Frequently Asked Questions (FAQ)

FAQ: 1. How can I detect communication faults between a 1794 AENT remote module and a 1756-L55 Processor without causing a controller malfunction?

Answer: - One method to implement a safety measure is to utilize status bits available from the module to establish a watchdog system that can detect and disable all related outputs in case of a fault.

FAQ: 2. Are there specific status bits available from the 1794 AENT remote module that can be used for communication fault detection?

Answer: - Yes, you can utilize status bits from the 1794 AENT module to set up a system that can detect faults and disable outputs when necessary.

FAQ: 3. What is the purpose of implementing a watchdog system for communication fault detection between the 1794 AENT remote module and the 1756-L55 Processor?

Answer: - Implementing a watchdog system can help ensure the safe operation of the system by quickly identifying faults and taking appropriate actions to prevent malfunctions without affecting the controller.

FAQ: 4. How can I ensure the reliability of the communication between the 1794 AENT remote module and the 1756-L55 Processor?

Answer: - By setting up a watchdog system using status bits and implementing safety measures, you can enhance the reliability of communication and prevent potential malfunctions.

You must be a registered user to add a comment. If you've already registered,
sign in. Otherwise, register and sign in.