Hello Siemens team! I have been encountering intermittent SF faults on our S7-300 (6ES7 315-2AH14-0AB0) CPU. Upon checking the diagnostic buffer, I have identified key events: Event 8 out of 10: Event ID 16# 2943 indicating an I/O access error when writing to area P, specifically at address 322. The requested OB is OB122, which seems to be disabled or not available in the current operating mode. This external error has been causing disruptions. Additionally, Event 7 of 10: Event ID 16# 4563 shows a STOP due to an I/O access error (OB not loaded or possible, or no FRB) in FC number 106 at module address 264. The CPU switches from the previous operating mode of RUN to STOP internally, leading to an internal error. Event 8 points to analog output PQW322, which has been verified in the program. Despite replacing the analog output module containing this address, the issue persists, with occasional errors related to address PQW320 as well. I am aware that including OB122 can prevent the CPU from stopping, but I prefer to address the root cause of the problem. I have attached the diagnostic buffer for further analysis. Is there a way to also provide the program, which is around 1.05 MB in size? Thank you for your assistance in troubleshooting this issue.
What type of module is PQW320/PQW322 and where is it located - in the central rack, on Profibus, or on Profinet? With no other relevant information in the diagnostics buffer and having already replaced the module, potential causes to consider include a backplane issue, improperly connected terminal modules, a defective terminal module, or improper connection of the termination module. Issues with neighboring modules may also affect the PQW320/PQW322 module.
JesperMP inquired about the type of module PQW320/PQW322 and its location within the system. The diagnostic buffer shows no other relevant entries, suggesting a potential backplane issue or a problem with terminal modules connectivity. There may also be an issue with neighboring modules affecting PQW320/PQW322. The module in question is an analog output module: 332-5HF00-0AB0, located at the end of the rack. Despite replacement, the problem persists. Address errors have been checked in the programming and configuration, both appearing to be correct. Attached is the HW configuration image for reference.
Consider exchanging the U-shaped connector between the modules to troubleshoot hardware issues. Additionally, if the wiring allows, try swapping the 2 last modules in both the hardware configuration and physical placement. This can help identify any potential connectivity issues and improve overall system performance.
In a forum discussion, JesperMP suggested troubleshooting by swapping the U-shaped connector between modules. This back connector is crucial in linking one module to the next in the system.
Absolutely!
Hi there! It sounds like an annoying issue indeed. One possibility to check is whether this issue is caused by cycle time overruns or EMC issues. For the former, optimize your program to reduce cycle time. For the latter, ensure you have proper grounding and shielding in place. Also, have you checked for a device addressing conundrum? There might be a configuration error leading to these I/O access glitches. As for sending your program, a common practice is to host the file on a cloud drive and then provide the link for Siemens to download. Please make sure to mask or remove any sensitive information prior to sharing. Good luck!
Hi there! It sounds like you’re dealing with a frustrating issue. Since you mentioned replacing the analog output module without resolution, I’d suggest double-checking the wiring and ensuring there aren't any loose connections, as that can sometimes lead to intermittent access errors. Also, look into whether there are any conflicts with the DB (data blocks) or shared resources that might be affecting the functionality of OB122. If you haven’t already, running a full diagnostic on your I/O configuration settings might reveal some hidden issues as well. Sharing the program might help others spot nuances that could be contributing to the fault. Good luck with your troubleshooting!
It sounds like you're dealing with quite a complex issue, but you’re on the right track by checking the diagnostic buffer first! Since you've already replaced the analog output module and still encounter errors, I recommend looking into possible wiring problems or short circuits on those addresses, as they can often cause I/O access errors. As for OB122, I totally understand wanting to fix the root cause instead of just working around it—consider reviewing the conditions leading to the trigger of that block. Have you thought about checking other associated FCs for unexpected behaviors or conflicts, especially around the faulty addresses? Keep us updated, and good luck with the troubleshooting!
✅ 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 I/O access errors could be caused by issues such as disabled or unavailable organization blocks (OBs), incorrect addresses in the program, faulty modules, or errors related to the operating mode.
Answer: Answer: To address intermittent SF faults, it is important to analyze the diagnostic buffer for key events, verify addresses in the program, check the status of organization blocks, and ensure proper module functioning.
Answer: Answer: Including the necessary organization blocks, such as OB122, can prevent the CPU from stopping due to I/O access errors. However, it is recommended to identify and resolve the root cause of the problem for a permanent solution.
Answer: Answer: Troubleshooting steps may include verifying addresses in the program, checking module functionality, analyzing diagnostic events, ensuring availability of organization blocks, and addressing any external errors causing disruptions.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.