Our project utilizes easily accessible materials to create a HMI (Human Machine Interface) screen that can interface with ABB Robots. Our screen is planned to communicate with the robot, display important information, perform movement tasks, and otherwise do similar operations to a regular HMI screen at a fraction of the cost.
The HMI runs on a Raspberry Pi, and utilizes a Python script to fill a display window with our screen design. Everything on the screen is created through Python code, and we are working to make the screen more customizable if possible. Our only materials used are a Raspberry Pi, Raspberry Pi Touchscreen, and an ABB robot given to us by our sponsor, Flex Automation.
Goals and Completion Strategies:
At the beginning of the semester, we created an Initial Project Specification document that would provide a loose timeline for our goals.
Our Functional Requirements were listed as follows:
- The entire device will have design files originated entirely from free and open source software.
- The HMI Screen will operate without a PLC, thus being cost efficient.
- The HMI Screen will communicate with the given robot, able to send IO signals back and forth between the devices.
- The HMI will have a simple, easy to understand interface.
- The HMI will display important information about the robot.
- The HMI will have an integrated E-STOP that will cease all functionality of the robot until resolved.
Many goals were self-evident in their completion status. Functional Requirements 1 and 2 were to be kept in mind throughout the design process, while each other requirement had a plan of completion behind them.
Requirement 3 – Summary:
Python has a few libraries available that are utilized to connect with ABB robots, which can be used to send signals back and forth- such as Program Start, Robot Home, and other useful functions at the request of the operator. We’ve worked with ABB and our sponsor in attempts to get connection to and from the robot. We’re able to send messages to the robot, but we get no signal back- which is due to several factors. Factors include the robot we’re given being old, the software being a different version than needed, and the robot not having a PC interface.
Requirement 4 – Summary:
In industry, it’s important to create simple interfaces so that employees can be trained on and understand them as quickly as possible. Our HMI should have an easy enough interface to understand so that when someone is handed the screen, they can complete a simple task. We decided that our quantification of success for this goal would be exactly that- we ask someone who’s never seen the screen before to turn on an output.
Requirement 5 – Summary:
It would be helpful for the HMI to constantly track different robot statuses, examples being last time since maintenance, how long the robot has been powered up for, and program runtime. We’ve experimented with timers, and have figured out code in our earlier versions that can constantly count up until being reset. We also have an entire screen dedicated to IO, which can be implemented as soon as the robot connects to the Pi.
Requirement 6 – Summary:
E-STOP’s are integral to every design, especially for safety reasons- we implemented an on-screen button that halted all operation (screen switching, logging out) until the issue was resolved. Our E-STOP requires the operator to acknowledge the stop before they’re able to use the screen again.
Project Steps and Details:
Screen Creation and Modification:
Before the semester started, we took a lot of time to plan and communicate with our sponsor to make sure we were very clear on our goals. We drafted the screen layout and made plans to begin testing with the Pi IO while we made arrangements to transport an ABB robot to the lab.
We developed code in Python to create an interactive user interface with buttons and separate screens that would all be considered useful for the operator. The beginning of the semester was dedicated to testing different operations on our screens, such as password protection, developing buttons, triggering IO with on-screen commands, and opening separate windows to be used as alternate screens.
As the semester progressed, we remained in contact with our sponsor and gathered more materials, such as a Raspberry Pi brand touch screen that can be used with our program. We also got the robot into the lab around mid-semester, and got power to it fairly quickly. Aside from some known joint + encoder issues, the robot was working as expected.
The remainder of the semester was dedicated to connecting and communicating with our robot.
Connection to Robot:
The robot we were given from ABB is an older model with some problems we weren’t able to address by the end of the semester. Throughout our efforts to connect and send signals back and forth between the robot, we remained in constant contact with Flex Automation and took their suggestions and advice. Unfortunately, all of our attempts were unsuccessful. We eventually reached out to an individual who had used a Pi to interface with ABB robots in the past, and we were told that both our Robot Studio version and the robot itself were not equipped to interface with the Pi. The robot itself needs a PC interface, and there are plans to gather information about that directly from Flex Automation over the next few weeks.
We just added a button at the top of the screen labeled E-STOP, and when pressed, the whole screen fills with a window that has an ‘acknowledge’ button. It’s impossible to do anything else on the HMI until the acknowledge button is pressed, which closes the E-STOP window and lets normal function resume. In the future, we plan on attempting to implement a physical button for safety reasons.
Next Semester Plans:
We plan to communicate with the robot as soon as possible next semester. Now that there’s a clear idea as to what we need to do in terms of communication, we can remain in contact with our sponsor over break and gather the information necessary to get a running start. Most notably, we need to communicate with the employee who has interfaced ABB and Pi before, taking notes from him and asking for advice when necessary.
We also plan to add more to the HMI screen as soon as robot connectivity is proven. This includes quality-of-life commands such as Home Robot, Start Program, Maintenance Position, and other commands at the request of the user. We also plan to fully implement the timers required to determine how long the robot has been powered on for, as well as how long the robot has gone without maintenance.
Overall, we plan to use the remaining time to fix our errors and optimize our screen so that it can be presented to our sponsor as soon as possible.
Sponsored by Flex Automation – Bi-Weekly Meetings over Microsoft Teams
Initial Project Specification:
EtherNet/IP Anybus Adapter:
Technical Reference Manual:
PC Interface Manual:
EDS Files to Robot Studio:
Robot Communication Github w/ Examples: