Click the blue text to follow!
Old Li Talks Technology: The Matters of PLC Robot Control Remote Monitoring
1
An Unexpected Inspiration
Last week, the robotic arm on the assembly line suddenly stopped working, paralyzing the entire production line. The production manager was frantic, and the young engineers in the technical department couldn’t find the cause after working for a long time. In the end, I went over to take a look and found that there was an issue with the parameter settings of the function block in the PLC, which caused the robot controller to fail to communicate properly.
Don’t laugh; this kind of thing is too common in factories. I’ve been in this industry for over ten years and have seen many newcomers stumble in the integration of PLCs and robots. Today, I will share some insights on this topic, so remember a few key points, and you won’t panic when you encounter similar issues in the future.
2
Why Choose Function Block Programming
Let’s start with a basic question: why use function block programming for robot control instead of traditional ladder diagrams?
Think about it: ladder diagrams are developed based on relay control circuits and are suitable for handling simple logical relationships. However, robot control involves complex calculations such as coordinate transformations and trajectory planning, which can become cumbersome and lengthy when written in ladder diagrams. Function block programming is much more efficient for robot control than traditional ladder diagrams, as a single block can accomplish complex functions and can be reused, just like a juicer in the kitchen where you put in the fruit and press a button to get juice without worrying about how it cuts and mixes inside.
“I remember once a young engineer insisted on writing the robot control program purely in ladder diagrams, resulting in over a hundred networks. When problems arose, he couldn’t even find where to make changes. If he had used function blocks, it could have been done with just about 20 blocks.”
3
Key Points of Remote Monitoring
When it comes to remote monitoring, factories are now focusing on smart manufacturing, and what leaders love to see are those real-time data and equipment statuses on their phones. This may seem simple, but it is actually quite complex.
The configuration of communication parameters for remote monitoring systems is the first hurdle. I have seen many engineers unable to connect to devices, checking and checking, only to find that the IP address was written incorrectly or the communication port was not opened. Remember, setting communication parameters is like making a key; if one number is off, the door won’t open.
Take the robot from last week as an example; it used the Modbus TCP protocol to communicate with the upper computer. In theory, it should be quite simple, but the problem lay in the data area division. The robot controller’s data area starts from 40001, while we wrote 4001 in the PLC function block, missing a zero, which caused the PLC to continuously read incorrect data.
plc1
Collaborative Design of Robots and PLCs
Wang, you must remember that robot teaching and PLC programs must be designed collaboratively, which is something many newcomers tend to overlook. Robots have their own controllers and programming languages, while PLCs have their own programs; both must work well together.
For example, the ABB robot in our workshop must have its I/O variables set up in the RAPID program to correspond with the PLC function blocks. For instance, if the robot program defines a DO signal “gripper_on” to control the gripper, then the PLC function block must have a corresponding input point to receive this signal. Many faults arise from not clarifying this correspondence.
Additionally, robots have their own coordinate systems, and when the PLC sends commands, it must consider coordinate transformations. This is like two people speaking different languages needing a translator. Function blocks serve this role perfectly, “translating” the PLC’s commands into a language the robot can understand.
4
Troubleshooting Tips
How to check when problems arise? I have a simple method: first check the communication status, then troubleshoot the program logic.
If communication is not normal, no matter how good the program is, it won’t work. Use the PLC’s built-in communication diagnostic function to see if there are any error codes. Common errors include timeouts, CRC check errors, and station number errors. Once communication is confirmed to be normal, check the specific parameters in the function blocks.
There’s also a lazy trick: embed a few status bits in the program in advance, such as communication success flags, command execution flags, etc. When problems arise, directly check these flags to save a lot of time. It’s like the fault lights on a car; when they light up, you know roughly where the problem is in the system.
5
Practical Advice
Finally, here are a few practical suggestions:
1. Make sure to comment on function block programs; you won’t understand them yourself after six months.
2. Remote monitoring data should be cached to prevent system crashes due to communication interruptions.
3. Regularly back up programs; I’ve seen too many people working overtime until dawn because they didn’t back up.
4. Learn to use simulation software for testing; it’s much better than debugging on-site while being scolded.
Remember, PLCs and robots are just tools. Once you understand the principles, the rest is just practice. No matter what brand of equipment, the basic concepts are the same. Start with simple function blocks, and gradually you’ll master complex applications.
