Is it feasible to acquire OPC data using a 1783-NATR device? After conducting research, it appears that OPC data may be restricted by a NAT. Is there a workaround for this issue, or is it not a viable solution? I am currently in the process of connecting a machine to a server for data collection. The machine is located on a separate network from the data collection server, so I must either adjust the machine's IPs or utilize NAT. Since I operate within a 24/7 facility, I am attempting to resolve this by implementing a NATR. I am utilizing ControlLogix with a 1756-EN2T Ethernet card. All control equipment is situated on the private side of the NATR, with only my computer and a Historian server on the public side. Both sides of the NATR are connected to an unmanaged switch. The NATR is functioning as intended. I am able to access everything (PLC, HMI's, etc.) from the public side by utilizing the necessary NAT rules. However, I am encountering difficulties in retrieving data from the machine. As I am not very familiar with Historian, I have cross-checked everything using an Excel spreadsheet that I created for tracking data with RSLinx Classic OPC. Despite being on the NATed/public side, I am unable to extract any data via OPC to the spreadsheet from the PLC. However, when I connect my computer to the PLC/private side of the NATR, I am able to collect data normally, confirming that my spreadsheet is functioning properly.
To optimize network performance and enable efficient communication, ensure that NATR permits OPC port 33xxx traffic. Typically, NATR only allows CIP and PTP protocols, with the possibility of multicast. Check for a multicast checkbox and utilize the exception form to add OPC port 33xxx as needed for seamless operations.
Thank you for your response, Cheeseface. After conducting a thorough search, I was unable to locate any specific ports in the 33xxx range for OPC. However, after further investigation today, I was able to resolve the issue. It turns out that no special port rules needed to be added to the NATR. The problem was that my RSLinx Topic Configuration was not updating to the new/external IP address despite my attempts to do so. To solve this, I added a second DDE/OPC Topic Configuration with a different name in RSLinx, updated the name in my Excel spreadsheet, and successfully retrieved my data through the NATR. Although I am unsure why I could not simply update the existing Topic, I am content with this resolution.
It sounds like you're running into some common issues with NAT and OPC communication, which can definitely be tricky! One potential solution you could explore is setting up a dedicated OPC server on the private side of the NATR and then using a tunneling approach or port forwarding to allow secure access from the public side. This way, you can bridge the communication gap without having to change your entire network setup. Additionally, make sure that the OPC server settings allow access from the public IP addresses you’re using. It might take a bit of trial and error to get it right, but with the right configuration, you should be able to scrape that data without needing to revert to the private network. Good luck!
It sounds like you've put in a lot of effort troubleshooting this setup! NAT can definitely complicate OPC communications, especially when it comes to maintaining the correct routing of requests and responses. One common workaround is to ensure that your OPC server is configured to allow connections from the public side of the NATR, and that it knows the correct path or port forwarding back to the private side. Additionally, check the OPC security settings and firewall configurations on both sides — sometimes, obscure security policies can block those connections. If you've verified everything and still face issues, consider using a VPN or a direct port mapping, which could simplify the connection without relying on NAT complexity. Keep pushing through—usually, the right tweak will get you over the hurdle!
✅ 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: - It is feasible to acquire OPC data using a 1783-NATR device, but there may be restrictions imposed by the NAT that need to be addressed.
Answer: - One potential workaround to the OPC data restriction caused by the NAT is adjusting the necessary NAT rules to allow data flow from the machine to the server.
Answer: - To resolve difficulties in retrieving data from the machine when using a NATR, ensure that the necessary NAT rules are properly configured to allow data communication between the machine and the server.
Answer: - The inability to extract OPC data to a spreadsheet from the PLC when on the NATed/public side may indicate issues with the NAT rules or configuration that need to be addressed for proper data retrieval.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.