Programming languages pave the way for the reign of robots

Robot roundtable

This article is part of a series on how to prepare for the reign of robots through:

Programming languages are having a profound impact on robot integration in industrial machines. Robots are taking over the world. Some countries are so concerned with rapid robot expansion that there’s been discussion of a robot employment tax to countermand the displacement of workers caused by robot implementations. Chinese appliance maker, Midea, riding the momentum of its $4 billion acquisition of Kuka, intends to fend off Japanese competitors and dominate the world’s largest robot market.

There’s a lot at stake. With the rise and convergence of the Industrial Internet of Things and collaborative robot applications, the possibilities are endless. And a sure sign of the times was Schunk’s collaborative robot gripper, with embedded intelligence and two cameras, winning the Hermes Award at Hannover Messe 2017.

The sky’s the limit on robotic industrial applications. We asked a variety of industry experts some specific questions about where robots are headed and how they plan to get there.

Since almost every robot manufacturer utilizes a different programming language, is there a common denominator, such as Python, or a development platform that engineers should know as a foundation? And is there any chance of standardization in the near future?

Matthew Bush, Hirebotics: We have found that individuals that have a strong background in any programming language are able to pick up the various robot languages; as at the end of the day most languages are more similar than they are disparate, and, once you understand logic flow and how to structure the program, half the battle has been won. I think that, as companies that provide off-line programming tools continue to evolve their platforms making them easier to use and more robust, we may see a point where you are more inclined to learn one off-line tool and then become robot-agnostic because it’s less important to know the native language. We are seeing this in the world of software development where for the past 10 years you have had mobile-app developers that were very specialized; they either wrote apps for Android or iOS, but rarely both. With the recent advent of React Native, you now can learn one language and deploy mobile apps easily onto multiple platforms, written by the same developer. I believe the same thing will happen with robot software to continue to the fast pace of implementation.

Matthew Bush is COO and co-founder at Hirebotics.

Lee van Every, Cenit North America: A universal software is often a good start when it comes to programming robots. That has become a competitive market actually, as there are several new software solutions available for creating viable output that can be utilized by the multitude of robot brands. More and more, solutions are being driven by 3D-simulation platforms that offer a graphical depiction of the robot world.

In making a decision on software, automation integration companies may want to look at the history of the software vendor, as well as how the software has been developed to meet industry needs—user-friendly interface, complex simulation, infrastructure for Industry 4.0. The future development of software products is also important. Some companies want to offer a complete digital factory solution and have the resources to do so, while others may just stick with certain applications within automation, like CAD to Path only, for example.

There are some standards already in place, but the question is will they remain as automation evolves? The OPC-UA is a good example of that. This is a communication protocol that allows machine-to-machine communication for industrial automation. Software can communicate with a virtual robot and respond or react accordingly, so the simulation is 100% accurate.

Another thing to consider is what structural platform the programming software is based on. Is it some unique language that only a few people are experts in, or is it more common like C++? Is the software flexible enough that a development group can implement internal knowledge into the product? All important questions for companies that want to use simulation-based software for automation development.

Lee van Every is senior account manager at Cenit North America.

Henrik Jerregard, ABB: As with fieldbuses, there exist many different languages with different strengths and weaknesses. A standardization in the short term is unlikely. Robot Operating System (ROS) Industrial is one initiative with these ambitions.

Henrik Jerregard is global product manager, robot controllers at ABB.

Marissa Tucker, Parker Hannifin: The answer to this question varies drastically if you’re asking about industrial robotics and factory automation versus lab automation or embedded motion control solutions.

In the industrial space where programmable logic controllers (PLCs) have long reigned as the control king, robotic systems and languages have developed around these languages. Although there is some variation between manufacturers, the IEC 61131-3 programming standard, which includes sequential function chart (SFC), ladder diagram (LD) and continuous function chart (CFC), has been adopted by nearly every PLC manufacturer, and its acceptance is growing rapidly among machine builders. IEC 61131-3 is important to robotics as this standard has expanded to include motion control through PLCopen Motion Control and more recently to robotics through the PLCopen 4 substandard.

The benefits of a robotics standard, like the benefits of IEC 61131-3, are immense to the industry. Many robotics manufactures provide their own proprietary languages, making it difficult to integrate a robot into a machine that already has a PLC or PAC using IEC 61131-3. In this case, machine builders must learn a new proprietary language each time they implement a robotic system, requiring the programmer to start their education from scratch each time they use a new product, increasing the time to market. Using multiple devices and languages in a system increases the complexity of the machine, making maintenance and debugging difficult. With the adoption of the PLCopen 4 programming standard, all of this can be eliminated.

With PLCopen 4, robotics will be able to be directly controlled by the PLC or PAC, providing full-machine, central control. In addition, machine developers will be able to use a language that is consistent across different manufacturers. The ability to program robotics, motion control and PLC logic in a single device is a huge advantage, as programmers need to learn only one standard language and program one system.

The response is very different for lab automation and embedded controls. In this industry segment, instead of the PLC or PAC being the central control, generally the PC or another embedded device is the master, while the motion control or robotics is taken care of by another device. The preferred method of communicating to the motion controller is usually through some type of API in C#, C++, VBA, or Python, as you’ve mentioned. Usually the libraries that manufacturers provide to talk to their devices run the gamut of the most commonly used languages. The challenge is that the robotic and motion commands sent from the programmer’s application is still in a proprietary command language. These proprietary motion languages create a huge burden on both the programmer and future maintenance personnel. Although the industry does have players to the market such as ROS trying to create a standard, it is still far from experiencing widespread adoption. Although this industry could significantly benefit from standardization, it is unlikely to happen, as this space is usually an early adopter of new technologies fresh out of R&D without time for standardization.

Marissa Tucker is product marketing manager, controls and HMI at Parker Hannifin.

Brian Carlisle, Precise Automation: Most robot languages have evolved based on application support and local culture. Some robot companies offer a robot programming language based on a well-accepted standard, in our case, VisualBasic.net, so that application engineers can learn to program the robot quickly. Other companies have developed languages that have characteristics that are well-accepted in, say, Europe or Japan. There is a trend toward trying to offer graphical programming interfaces for simple applications. These work OK for very simple tasks such as machine loading with a bit of I/O to interlock with the machine. However, many applications require fairly extensive error handling, which is not easy to do with these simple graphical interfaces, given all the things that can go wrong. So often, what starts out as a simple demo with a graphical interface evolves in a more complex programming exercise to accommodate error handling, data logging and communication with supervisory systems. There have been some efforts to develop a standard programming language, especially in Japan, but these efforts tend to run up against application problems, as vendors often want to offer higher-level instructions to make programming a specific application easier. Just one example in arc welding is a “weave” instruction, which superimposes a weaving motion on a nominal welding path to fill in gaps in a seam. Programming this in C#, for example, would be complex and difficult to understand. So a trend is to move toward fairly standard language structures, with the addition of special application instructions, based on markets served by the robot vendor. This is likely to continue. It is possible that off-line, graphical simulation systems will eventually have effective interpreters, which will generate native robot code for various vendors. Simulation vendors are working on this. This works OK for motions but gets more difficult for procedures for error handling, communication, machine vision integration and calibration.

Brian Carlisle is CEO at Precise Automation.

Patrick Laughter, Denso Products & Services Americas: Many robot manufacturers use programming languages similar to Visual Basic, C or Japanese Industrial Standard (JIS).

Patrick Laughter is engineering manager, robotics, Denso Products & Services Americas.

Ryan Guthrie, TM Robotics: There is indeed a common denominator; however, it is not so much a specific language. Rather, it’s a mindset. I have seen a number of robot programmers switch between robot brands and, in most cases, make the switch in hours. If a technician understands the key concepts of programming in general, then it is just a matter of understanding the little things that make each language unique. I have been leading the training efforts for our company for more than eight years now, and I find that as long as a user has some form of basic understanding of programming, from Basic to C to Python, making the jump into robot programming is pretty simple. A key concept that nonprogrammers need to understand, however, is that the robots do have a level of perceived intelligence. Most robot programmers are not actually writing source code for the controllers or robot arms. Instead, they’re writing code on an intermediary level, which is then compiled internally in the robot controller and combined with the kinematics and internal code to create the final motion profiles—just like you do not need to understand valve timing or fuel air ratios to drive a car.

Ryan Guthrie is executive vice president at TM Robotics.

Daniel Moore, Universal Robots: A basic understanding of programming concepts—variables, if/else logic, loops—is useful to any robotic application, but even this is not required for many basic applications. Universal Robots prides itself on having a graphical programming environment that is approachable and understandable by nonprogrammers and line operators, as easy to use as a smart phone, while other robots have their own programming languages.

Honestly, due to the competitive nature of robots, I do not expect to see a standard language or programming package in the future.

Daniel Moore is tech support manager at Universal Robots.

Mike Van Hoomissen, DWFritz Automation: Most robot programming languages are still proprietary to the manufacturer. For example, Epson, a SCARA and six-axis robot manufacturer, has a programming language that is close in look to VB6. Genmark, a wafer robot manufacturer, has a programming language that uses two-letter commands followed by parameters. For the professional programmer, most robot languages are learned relatively easily. Training is usually recommended, as any platform has its own best practices.

Mike Van Hoomissen is senior staff software engineer at DWFritz Automation.

Maximiliano Falcone, Kawasaki Robotics USA: For as much as there is common from robot language to robot language in regard to the major robot manufacturers, there is as much different. Many languages were built on scripting platforms, which were interpreted by the controller, and some of these have since transformed to more complex and complete languages with advanced debuggers and compilers. There are teams out there working to “communize” the control of robots. In my opinion, the biggest advances are coming out of Robot Operating System (ROS), allowing one software or control platform to operate many different robot platforms. Being an open-source robot language that is getting the support of many manufacturers worldwide, it is quickly becoming a force outside of personal and hobby robotics. Kawasaki’s next generation of robot controller, F- Controller, will have ROS compatibility features, which will enable integration of many of the ROS nodes in our standard robots. So reuse of code across platforms will be more seamless than ever before across robot brands.

From my experience, most of the modern programming languages—Python, C++, C#, Lisp, Java—are all beneficial to learn and master. As with any coding, more important than the language itself is the structure and intelligibility of the code itself. Learning any language will help in the long run; however, learning sound fundamentals and practices that will allow you to create efficient and understandable code will pay dividends in your career in robotics.

Maximiliano Falcone is senior manager, general industries engineering at Kawasaki Robotics USA.

Bhaskar Ramakrishnan, DWFritz Automation:

Choosing an underlying program is not just about function, but also about processing speed; this affects the cycle time. To modify legacy systems that use .Net or C programs means greater expenses. Another expense that needs to be considered is the training of the service as well as maintenance staff.

Bhaskar Ramakrishnan is technical sales engineer at DWFritz Automation.

Jim Lawton, Rethink Robotics: Programming is a significant roadblock for many companies that are trying to deploy robots, an issue that our company has sought to address since our founding. Every type of robot requires a unique set of programming knowledge in order to deploy it effectively, creating massive inflexibility. This is why we brought train-by-demonstration to the market, so engineers can easily deploy robots without spending hundreds of hours programming.

The reality is that companies deploying traditional automation will need expertise in a variety of programming languages in the short term. For collaborative robots, that roadblock has already been removed.

Jim Lawton is chief product and marketing officer at Rethink Robotics.

ALSO READ: How to get started with robotics

About the author

Mike Bacidore is the editor in chief for Control Design magazine. He is an award-winning columnist, earning a Gold Regional Award and a Silver National Award from the American Society of Business Publication Editors. Email him at [email protected].