Hello, I'm curious if anyone has successfully utilized Allen Bradley PLC with OPC communications. This emerging technology can be challenging, as many tech support resources are still navigating its intricacies. Despite following knowledge base ID: QA67232, I am still encountering difficulties. Currently collaborating with Rockwell, I wanted to seek additional insight here. Specifically, I am working with a 1756-L82E model and attempting to validate its functionality with the demo program. I am encountering an MSG command error, as shown in the attachment. Have any individuals managed to overcome this issue?
Many OPC servers retrieve data from PLCs by interfacing with .NET Studio through InGear communication drivers.
Hello there. Based on my understanding, Rockwell PLCs do not include OPC UA functionality. If your project requires accessing data from an OPC UA server, there are multiple ways to accomplish this. I can suggest middleware options that may require a financial investment. Alternatively, members of this community who are knowledgeable in Python might recommend open-source solutions that require some effort on your part. I can provide you with my solution, but it comes with a price tag of several hundred dollars per license. It's worth noting that I am not selling this software. If you prefer open-source options, let's hope for some helpful recommendations.
I have saved this thread for future reference in case I need to use the ControlLogix v36 OPC UA Server. Hello everyone, I am excited to share my discoveries on setting up the new OPC UA server, especially for those interested like JeremyM :lolis:. Rockwell's documentation on this topic is limited, but I have reached out to them for more information. Stay tuned for updates! Visit www.plctalk.net for more insights.
Thank you for the responses. I was able to successfully configure my 1756-L82E PLC to communicate with an OPC simulation server, using both ProSys and UaAnsiC. These are popular free OPC Sim servers. Setting up the connection involved having one laptop as the OPC server host, the PLC as the client, and going online with the PLC on another laptop, all connected via a simple switch. However, I encountered challenges when trying to establish a connection with an OPC server that requires SSL certificates. Despite my efforts to reinstall the certificate, I have not been able to resolve this issue. If anyone has insights on this matter, I would greatly appreciate it. One helpful tip that may benefit others is that AB PLCs may encounter difficulties when the OPC server URL includes the server address at the end. For instance, "opc.tcp://169.254.127.244:48020/OPCUA/SimulationServer" does not work, while "opc.tcp://169.254.127.244:48020" works perfectly. This distinction could potentially save others from similar compatibility issues.
After encountering difficulties with establishing a direct connection between the customer OPC server and the PLC, I found success by incorporating FT Optix as an intermediary. This setup now involves communication flow from the OPC server to FT Optix to the PLC, enabling seamless messaging between the PLC client and other networked devices. To host FT Optix, options include the 1756-UM021A-EN-P (designed to fit into a control logix rack), the Factory Talk Optix HMI, or a separate PC to run the Factory Talk Optix software. The first two options include the necessary software, while the third option requires separate purchase of the software and a PC. In terms of pricing, the first two options likely offer the most cost-effective solution.
Absolutely, I have experienced similar growing pains with Allen Bradley PLC and OPC communications. From my experience, the MSG command error typically arises when the path to your target is incorrectly addressed. I recommend double-checking your targeting, specifically the communication module, node address, and slot numbers. Additionally, ensure each PLC component is correctly referenced in both your OPC server and Client Access software. I find that a meticulous approach often solves these complexities. Good luck!
Hey there, I had a similar experience when I first worked with an Allen Bradley PLC, specifically the 1756-L82E model. My issue was an incorrect setup of the MSG block in the PLC code. What worked for me is ensuring that the communication path in the MSG block is correct. Remember, each device you're communicating through counts in the path. Also, you might want to double-check the data type that's being sent or received. If it's not compatible with what's on the receiving end, that'll also throw an error. If you've checked these and still have issues, don't hesitate to reach out. Happy to assist! Good luck!
✅ 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: OPC (OLE for Process Control) is a standard for communication between different devices and software in industrial automation. Allen Bradley PLCs can be integrated with OPC servers to enable data exchange and monitoring.
Answer: Answer: Some common challenges include compatibility issues, configuration errors, network communication issues, and troubleshooting difficulties due to the complexity of the technology.
Answer: Answer: Troubleshooting an MSG command error may involve checking the configuration settings, ensuring proper network connectivity, verifying the message format, and consulting technical resources such as knowledge base articles or contacting the manufacturer's support team.
Answer: Answer: Community insights can provide alternative perspectives, troubleshooting tips, and potential solutions based on others' experiences with similar challenges. Collaborating with peers who have overcome similar issues can often lead to quicker resolutions.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.