Hello everyone, I recently set up a 5069-AENTR rack with OA16 and IA16 modules in specific slots. The first group of six IO modules and the last group of three IO modules are experiencing frequent loss of logical connection (error code 203) throughout the day. These connection issues occur independently in each group and can last anywhere from a few seconds to several minutes. I have already tried adjusting the connections between modules but will be conducting a thorough inspection of the entire rack soon. One potential solution I came across is disabling time synchronization (1588 PTP) on the 5069-AENTR. I found a Knowledgebase article (QA67023) that provides instructions on how to do this using the ptpcmd tag, but I couldn't locate the specific details I needed. I am considering trying this as a last resort to see if it resolves the connection issues. Additionally, I recently upgraded the controller and made some changes to the network setup. The network includes multiple 1794 Flex racks and PowerFlex 70 drives, with the EN2T module showing a low CPU utilization and stable network connections. Despite troubleshooting efforts, the connection problems persist, and I am seeking advice on potential solutions. Any insights or suggestions would be greatly appreciated. Thank you. @Davidvu, I noticed you mentioned having the document I am looking for in a previous post. Any chance you could assist me with this issue?
Unfortunately, I missed the 30-minute window for additional details in AENTR:S tags. The IO packet rate remains steady at 210-215, with CIP timeouts count close but not exactly matching the blips. CPU utilization fluctuates between 1 and 3%. When analyzing time sync in the AENTR module properties, I noticed that CIP Synch time synchronization is enabled. The UTC system time currently reads 1/2/1970 6:xx:xx AM, with the grandmaster clock and local clock sharing the same identity. The L81 time displays the correct 2024 date and time. Interestingly, Enable Time Synchronization is not checked on L81, indicating it is not the CST master.
Impressively, the document linked makes mention of IA-AT003 on pages 1-5. It appears that there may be an error in the link provided by RA as the document is not accessible. However, based on the context of the message, it seems they are utilizing the service "Set Single Attribute" (0x10) to adjust the value of PTP Enable (Attribute 1) within the Time Synchronize object (class 0x43) for the sole instance of that class (Instance 0x01). The data being written is a single byte, aligning with the definition of PTP Enable as an 8-bit decimal integer. Typically, a value of 0x01 indicates enable while 0x00 signifies disable for such attributes. Therefore, it is likely that a 0x00 is being transmitted in the ptpcmd tag, which is assumed to be a SINT, effectively deactivating the PTP service within the module. In light of the broken link, feedback has been submitted on the technote to address this issue. Upon reviewing the specifications, it has been confirmed that 0x00 corresponds to disable, and 0x01 corresponds to enable.
I was hesitant to send a zero due to uncertainties in the running system. However, after setting up a read attribute, I confirmed that a 1 was indeed read. When I attempted to send 0, the MSG failed with error code 16#0010, indicating that the module's mode or state prevented the requested service. It was a disappointment, but I will see what tomorrow brings. My understanding of CIP time synchronization is limited, but I acknowledge its existence.
Today, I dismantled and reassembled the rack, making sure everything was in order. I rearranged the IO module positions while doing so. After saving the project as a L5K file and importing it into a new project, I downloaded it and replaced the old Hirschmann switch with a new Stratix 5200. I ensured that the new switch was integrated into the IO tree, but did not configure smartports or any additional settings. Despite my efforts, the issue persisted. An interesting observation is that the input data from slot 8 does not reset during disruptions such as disconnecting the Ethernet cable or unplugging the AENTR power. While slots 2 & 4 behave correctly, slot 6 has not been tested due to lack of inputs. The longevity of slot 8 holding the input status has been a temporary solution, but I am running out of ideas for a solution. I suspect there may be a software, firmware, or hardware issue at play, which I will investigate further on Monday. Another option would be to reinstall the old SLC rack, but this would require additional time which is in short supply.
Is there a possibility of MAC collisions occurring within the DLR ring nodes? It is essential to manually set all nodes on the ring to 100Mbps full duplex and disable auto-negotiation. Additionally, consider utilizing the DLR Tool to detect and address any potential issues within the network.
Hey there, it definitely sounds like a tricky issue you've got on your hands! Based on my experience with 5069-AENTR racks and the error code you provided, the issue could be caused by a variety of factors. However, one cause could be the rack's communication setup. You mentioned having done network changes recently. Sometimes, even small adjustments can inadvertently cause configuration mismatches. I would suggest re-validating all of your network and module settings, including essential parameters like IP addresses, subnet masks, and gateway settings. Meanwhile, regarding the QA67023 article, I don't have it handy but I think @Davidvu could assist as you pointed out. Good luck, and keep us posted on your progress!
Hi there! I've definitely seen issues like this before. One thing I'd suggest is to examine your AENTR modules' hardware version, if not already done so. There's a known issue with certain versions where they may have a lower tolerance to stacked switches or a more complex network topology. As for the '1588 PTP' solution, it's worth a shot indeed but bear in mind that it's often only effective if your Controller and EN2T module need to share a common time reference. If they don't, the benefit could be negligible. Is there any chance that you have any third-party network devices on your rack? Those can often cause some situational problems too.
Hey there! It sounds like you’re having quite the challenge with those connection issues. Disabling the time synchronization does seem worth a shot, especially since it could reduce the load on the network. As for the knowledge article, I recommend checking if your firmware is up to date, as compatibility can sometimes be a hidden factor. You might also want to inspect the physical connections and the power supply to each module, since intermittent issues can sometimes stem from something as simple as a loose connection. Hopefully, you find a lasting fix soon—hang in there!
✅ 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 connection issues could be caused by various factors, such as faulty connections between modules, network setup changes, or potential software-related issues.
Answer: Answer: You can try adjusting the connections between modules, conducting a thorough inspection of the entire rack, and considering solutions like disabling time synchronization (1588 PTP) as a last resort.
Answer: Answer: You can refer to Knowledgebase article QA67023 for instructions on disabling time synchronization (1588 PTP) using the ptpcmd tag, although specific details may need to be located for the process.
Answer: Answer: Seeking advice on potential solutions, such as disabling time synchronization (1588 PTP) and ensuring stable network connections, can help in resolving the persistent connection problems.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.