How Much Programming Expertise Do We Need to Integrate Robots in our Machines?

Should cost and connection questions on robotics hinder our integration plans?

By Mike Bacidore

We keep hearing about the lower cost of robotics and how easy they are to program now, so we’re looking at integrating robots into our packaging lines.

First, which programming languages do our engineers need to know? Do we need a computational model for programming robots? Second, what about connecting? How difficult is the integration? Is it just Ethernet and an RJ45 connection? Are there wireless options?

Join in the discussion below. 

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p>The programming language ABB engineers use is called RAPID. It is a kind of second tier of language base one C++. It is a friendly using language and ABB provides relative training course to teach programming. ABB provides a few of connection ways including Ethernet, Devicenet, PROFIBUS, PROFINET and so on to meet different requirement of customers. To meet the safety requirment there is no wireless option at the moment.</p>


  • <p>Universal Robots is developing 6-axis robots with the emphasis on, anyone with any skill level can program them. By allowing a company that has never interfaced or even used robots before the ability to 'Do it themselves' that opens up significant opportunities within 1000's of small and medium size companies worldwide. Our robots are simply programmed by physically showing them where to go.There is tremendous value to all size companies to be able to quickly ( with hours) deploy a robot. Again Universal Robots is laser focused on simplicity. We have wide range of interface option to make integration simple. - 16DI/16DO - 4AI/2AO - Ethernet TC/PIP - Modbus TCP</p> <p>All discrete and network I/O is easily accessible within our 'Polyscope' enviornment</p> <p>Edward Mullen - Universal Robots National Sales Manager Americas </p>


  • <p>Which language your engineers use depends on the solution you choose. Some packaging lines use dedicated robot controllers that coordinate with the main machine controller. For example, a Fanuc robot connects to an Allen-Bradley® ControlLogix® programmable automation controller (PAC) using EtherNet/IP™. In this scenario, the robot is programmed using dedicated software that’s different from the main machine controller. </p> <p>The other approach is to use the built-in capabilities of the machine controller. With this approach, all programming is done in the same environment and the robot is controlled by the same PAC as the main machine. In the case where a separate robot controller is used, integration varies. In some cases, the integration using EtherNet/IP is straightforward and typically uses a standard RJ45 Ethernet connection. Once programmed, it’s possible to change various robot parameters from the main machine controller over the network using an add-on instruction dedicated to the task. The same network connection can also be used to coordinate movements, and deliver all machine control and information services. However, not all robot and machine controllers work together as seamlessly so it’s worth checking first. </p> <p>-Amy Peters, manager of business strategy and portfolio planning, Rockwell Automation</p>


  • <p>From a smaller robotics application approach, such as SCARA, Cartesian or even smaller sub $1200 turn key single axis linear actuators with Ethernet/IP, most end users and OEM machine builders seem to prefer a single software package to develop both PLC and robotic motion. The primary reason given, is that their staff is already versed in ladder logic, and sending staff maintenance or engineers to third party robot training to learn a different language is costly to them or they have already invested in one brand or a larger six axis solution company.</p> <p>One approach to integration is the creation of a function block in the PLC software package and utilizing existing field-bus technology to communicate the data required from PLC to robot controllers. Yamaha Robotics creates a low level interface that works with field-bus registers and something like an Add-On-Instruction (AOIs) from Allen Bradley can be created to send the proper values to the firmware in the robot controller by mimicking high level robot commands. This is generally sent over via Ethernet/IP and sequenced all in ladder logic. This is a "step-up" from the old school way of coding in native robot language and exchanging I/O field-bus interface bits.</p> <p>Yamaha Robotics provides FREE custom AOIs or FB blocks that are created in the PLC that provide a simple interface to send simple actions to the robot. These might be actions such as "servo on", "move to point 1", "move to this x,y,z,r", etc...Low level commands don't require an additional "rack" or "motion card" installed in the PLC because they utilize existing field-bus connections. In most cases, interfacing does not require anything special in the PLC either, such as CIP motion or a motion capable PLC. This also further reduces cost to the customer because now they can make a simple single axis of motion move in a PLC ladder rung without motion hardware, using existing field-bus and programming movement via ladder logic from a vendor supplied function block.</p> <p>Our Integration page has a view samples of this concept: <a href=""></a></p> <p>Chris Elston - Yamaha Robotics USA Sr. Controls Engineer</p>


  • <p>The debate on how robots are programmed and integrated has existed since the introduction of the first robot in the 1960’s. Despite this ongoing interest by users, robot programming is still not standardized, with each robot maker offering their specific programming language. On the PLC side, there has been a move to standardization with all major PLC’s supporting a subset of the IEC-61131 programming languages. </p> <p>Yaskawa Motoman was one of the first major robot makers to introduce a PLC-based robot controller, MLX. Yaskawa’s approach involves eliminating traditional robot programming and putting every aspect of robot configuration, programming, maintenance, etc. on the PLC. This disciplined approach means there is only one system to learn and maintain. Other major robot vendors have followed suit, but have offered a “hybrid” solution that still involves the traditional robot controller. Using this hybrid approach, robot vendors are offering an “easier” data exchange with the robot controller or limited programming of the robot from the PLC while still requiring some programming on the robot controller. This hybrid approach distributes the robot program on to two platforms: PLC and the robot controller. This is worse in our opinion than the old way of simple IO handshaking between the PLC and the robot controller.</p> <p>Yaskawa’s MLX Unified Robot Controller offers the following capabilities:</p> <p> • Configuration, programming, and maintenance of the robot: MLX200 from Yaskawa offers this capability for Rockwell PLC’s in RSLogix 5000. Both an Add On Instruction (AOI) library and prebuilt robot HMI in Factory Talk View are provided. See • Hardware and software integration of robot with tooling, peripherals, HMI, safety, etc.: All of this is done using RSLogix 5000 and hardware from Rockwell Automation. Even conveyor tracking is accomplished using Rockwell motion and servos. No special software or hardware is needed to do this. See • Application software for easy robot programming: Yaskawa offers full featured palletizing software (PalletSolver) that eliminates the need for programming of palletizing functions. PalletSolver is offered as an addon to RSLogix and does not require any external computer. See <a href=""></a></p>


  • <p>If your engineers know any programming language they can pick up Robot programming quite easily for the tasks most people need to handle on the robot-level for packaging (movement, I/O and timing). The popular brands of robots can be taught to people with no programming experience; an engineer should be able to learn one quickly enough, which I believe why there hasn't been a significant push for standardization. </p> <p>Brand-independent 3rd party offline software can help alleviate some of this, but you still have to understand what the code is going to do. </p> <p>What I find interesting is the push to have PLC control on the robots because this is what many engineers understand ... but the robot programming languages are so robust, developed and easy to navigate, I would question the layer of PLC abstraction on top of a fully functional language (other than potential time loss between controllers, which is a different topic)</p> <p>Most modern robots have multiple ways of integrateing, but will have all or a combination of Serial ports, Ethernet, Devicenet, PROFIBUS, PROFINET </p>


RSS feed for comments on this page | RSS feed for all comments