Troubleshooting 1747-sn Fault: Specialty I/O Module Not Responding

Question:

Hello, I am experiencing a 57h fault where the Specialty I/O module is not responding to a lock shared memory command within the required timeframe. This fault occurs randomly and, while it can be reset and run fine temporarily, it keeps reoccurring. We have already replaced the scanner card, but the issue persists. Upon reviewing an old printout detailing the connections, I discovered that the faulty module is connected to (3) 1791 I/O modules, (2) 1771 PLCs, and a PV600. The scanner card is housed in a 1746. Although I have not located all the devices in the facility yet, I have verified the functionality of (2) 1791 modules, (1) 1771 PLC, and the PV600. They all appear to be functioning properly with no faults. Can anyone offer any suggestions? I have also checked the connections of the devices I have found so far.

Top Replies

Thank you for providing those details! Since the issue is related to backplane communication, it is unlikely that the problem lies with the RIO network or RIO devices. If replacing the 1747-SN RIO Scanner did not resolve the problem, the root cause may be a failing backplane or power supply. There is a small chance that mis-addressed Block Transfer buffers could be causing the xx57h fault, especially if the same buffers are used in multiple block transfer functions. However, this issue is more commonly associated with the redundant 1747-BSN rather than the standard -SN. If the program has not been recently modified, this is an unlikely cause. If there is an available slot in the chassis with the SLC-500 CPU, you may want to consider moving the 1747-SN and updating all related logic in that slot.

Thank you for responding! I have not noticed any changes in the program. After speaking with a tech expert from Allen Bradley, I learned that certain backplane dates are known to have issues. Unfortunately, I could not find a date on mine to verify this information. The tech also suggested checking the grounds, which appeared to be in good condition. However, due to the extensive size of the shop where this system is located, some connections may have been undone and I am unsure of their exact locations to inspect. Ultimately, we have decided to proceed with installing a new backplane.

From my experience with similar faults, you may want to inspect the integrity of the communication cables connecting the Specialty I/O module to the scanner card. The intermittent nature of the fault may suggest that there's a physical problem with the cable or connectors causing a break in the communication sporadically. Also, consider checking your system’s overall grounding; improper grounding can sometimes lead to weird system behavior. Remember to verify the data transmission rate for compatibility as well - all devices need to communicate at the same rate, a mismatch could be the reason for your fault.

More Replies β†’

Streamline Your Asset Management
See How Oxmaint Works!!

βœ…   Work Order Management

βœ…   Asset Tracking

βœ…   Preventive Maintenance

βœ…   Inspection Report

We have received your information. We will share Schedule Demo details on your Mail Id.

To add a comment, please sign in or register if you haven't already..   

Frequently Asked Questions (FAQ)

FAQ: 1. What does a 57h fault indicate in the context of the Specialty I/O module not responding?

Answer: - A 57h fault indicates that the Specialty I/O module is not responding to a lock shared memory command within the required timeframe.

FAQ: 2. What steps have been taken to troubleshoot the 1747-sn fault so far?

Answer: - The scanner card has been replaced, and the connections of the devices have been checked.

FAQ: 3. Which devices are connected to the faulty module in the setup described?

Answer: - The faulty module is connected to (3) 1791 I/O modules, (2) 1771 PLCs, and a PV600.

FAQ: 4. How frequently does the 1747-sn fault occur, and how is it currently being addressed?

Answer: - The fault occurs randomly and can be reset temporarily, but it keeps reoccurring.

FAQ: 5. What devices have been verified to be functioning properly in the setup?

Answer: - (2) 1791 modules, (1) 1771 PLC, and the PV600 have been verified to be functioning properly with no faults.

FAQ: 6. Are there any specific suggestions for resolving the 1747-sn fault based on the information provided?

Answer: - The thread does not provide specific suggestions for resolving the fault, so further troubleshooting or expert advice may be needed.

Ready to Simplify Maintenance?

Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.

Request Demo  β†’