# An Overview of Industrial Robots Control and Programming Approaches
## 3 Industrial Robot Control System
**(3) Limitations of programming languages:** In contrast to machine tool programming (based, e.g., on G-code), the lack of a universal, manufacturer-independent programming language complicates the integration of different robot technologies within a single production plant. Indeed, the language of each robot manufacturer (e.g., KUKA, ABB, Fanuc, Staubli) differs in complexity, syntax, and semantics, requiring specialized personnel [20]. Moreover, robot programmers are compelled to use basic commands and libraries. These cover the majority of standard programming needs, but they do not allow for performing advanced calculations and elaborate complex control strategies. Generalized offline programming tools (e.g., RoboDK, Siemens Process Simulate) use specific postprocessors to translate the 3D modeling commands and features into ready-to-use robot codes containing vendor-specific instructions. However, they still do not cover the entire function libraries of each commercial IR language and cannot replace a skilled user when more complex programming routines are needed. It should also be noted that the development of a standardized programming language is not supported by IR vendors, which typically do not provide detailed info on their low-level control schemas [21]. **(4) Limited motion control:** Complex robot paths (e.g., the ones required for robot machining, gluing, or precision assembly) cannot be efficiently applied via traditional programming, where the available motion instructions are in most cases limited to point-to-point (programmed in the joint space) or linear/circular movements of the robot end-effector [15; 16; 17]. In principle, one could discretize the desired non-trivial path into a set of smaller segments and proceed with the standard motion functions, although this would increment the controller's computational load and slow down the robot velocity due to the increased number of path corners. Indeed, with path cornering, the only settings available to the programmer are the maximum velocity and acceleration, while the profile type is elaborated by the controller and cannot be modified [22]. In general, the user has no access to any motion law (position vs. time and its derivatives) generated from the coded instructions. **(5) No disturbs compensation:** Undesired dynamic effects, which seriously affect the IRs' position accuracy and, thus, preclude their use in precision manufacturing tasks, cannot be compensated utilizing the standard control and programming approaches. This is primarily due to the limited user access to any low-level motion control algorithm running in the trajectory generator (see point 4). As for the hardware, it should be noted that the use of servomotor-side angular encoders does not allow for capturing the nonlinearities introduced by the speed reducers (e.g., hysteresis and dynamic lost motion) [6; 23; 24; 25]and, therefore, to provide rich feedback information to the controller [26]. At last, the update time of the controller's real-time module is usually too high (in the order of a few milliseconds) for the correction of high-frequency disturbances originating in the reducers. **(6) Outdated parts:** IR controllers comprise many obsolete electronic parts, starting from the main CPU (e.g., Pentium 4 single-core processor) and its related operating system (e.g., Windows XP). Moreover, the available space for data storage on the controller is quite limited (several times even 25 MB), and, therefore, the dimensions of newly downloaded items (programs and data files) must always be checked. To overcome these gaps and, thus, meet the need for collaboration, reconfiguration, and rapid modification of IR tasks, in the last decade, advances have been made both in academic research works and by robot manufacturers with the introduction of more flexible alternatives for IR control, which will be detailed in Section 4.