Programming Manual. Meca500

Transcription

1 Meca500 Document Version: 2.5 Robot Firmware: September 1, 2017

2 The information contained herein is the property of Mecademic Inc. and shall not be reproduced in whole or in part without prior written approval of Mecademic Inc. The information herein is subject to change without notice and should not be construed as a commitment by Mecademic Inc. This manual will be periodically reviewed and revised. Mecademic Inc. assumes no responsibility for any errors or omissions in this document. Copyright c 2017 by Mecademic Inc.

3 Contents 1 Introduction 1 2 Definitions and conventions Joint numbering Reference frames Joint angle convention Pose and Euler angles convention Joint set and robot position Units Key concepts Homing Cornering Inverse kinematic configuration Workspace and singularities Communication protocol General information Commands Motion commands Request commands Responses Joints and pose feedback Motion commands Delay(t) Gripper(e) MoveJoints(θ 1, θ 2, θ 3, θ 4, θ 5, θ 6 ) MoveJointsDelta( θ 1, θ 2, θ 3, θ 4, θ 5, θ 6 ) MoveLin(x, y, z, α, β, γ) MoveLinDelta( x, y, z, α, β, γ) MovePose(x, y, z, α, β, γ) AutoConf(e) i

4 5.9 SetCartVel(v) SetConf(c 1, c 3, c 5 ) SetCornering(e) SetGripperForce(f) SetGripperVel(v) SetJointVel(ω) SetMoveLinDeltaRef(n) SetTRF(x, y, z, α, β, γ) SetWRF(x, y, z, α, β, γ) Request commands ActivateJointsFeed ActivatePoseFeed ActivateRobot ActivateSim ClearJogMotion ClearMotion DeactivateJointsFeed DeactivatePoseFeed DeactivateRobot DeactivateSim DisableBrakes EnableBrakes GetAutoConf GetCartVel GetConf GetCornering GetJoints GetJointVel GetMotionStatus GetMoveLinDeltaRef GetPose GetSimulationMode ii

5 6.23 GetStatusRobot GetGripperStatus GetTRF GetWRF Home PauseMotion ResetError ResumeMotion SetEOB(e) SetEOM(e) SetOfflineProgramLoop(e) StartProgram StartSaving StopSaving Error handling Command errors Server errors Motion errors Status messages and command responses List of status messages List of command responses iii

6 This page is intentionally left blank

7 1 Introduction This document describes key theoretical concepts related to industrial robots, the communication protocol used for interfacing the Meca500 with a network client (PC, Mac, PLC, etc.), all the commands that can be sent to the robot, and the responses generated by the robot. Before reading this programming manual, you must first read the User Guide. 2 Definitions and conventions 2.1 Joint numbering The joints of the Meca500 are numbered in ascending order, starting from the base (Fig. 1). Figure 1: The reference frames and joint numbering for the Meca Reference frames At Mecademic, we use only right-handed Cartesian coordinate systems (reference frames). The reference frames associated with the Meca500 are shown in Fig. 1. The x axes are in red, the y axes are in green, and the z axes are in blue. The key terms related to the reference frames that you need to be very familiar with are: BRF: Base Reference Frame. Static reference frame fixed to the robot s base. Its z axis coincides with the axis of joint 1 and points upwards, while its origin lies on the Copyright c 2017 by Mecademic Inc. Page 1 of 36

8 bottom of the robot s base. The BRF s x axis is perpendicular to the front edge of the robot s base and points forward. The BRF cannot be reconfigured. WRF: World Reference Frame. The robot s main static reference frame. By default, it coincides with the BRF. It can be reconfigured with respect to (w.r.t.) the BRF using the SetWRF command. FRF: Flange Reference Frame. Mobile reference frame fixed to the robot s flange (mechanical interface). Its z axis coincides with the axis of joint 6, and points outwards. Its origin lies on the surface of the robot s flange. Finally, when all joints are at zero, the x axis of the FRF points downwards. TRF: Tool Reference Frame. The robot end-effector s reference frame. By default, it coincides with the FRF. It can be reconfigured with respect to the TRF using the SetTRF command. TCP: Tool Center Point. Origin of the TRF. (Not to be confused with the Transmission Control Protocol acronym, which is also used in this document.) 2.3 Joint angle convention The angle of joint i (i = 1, 2,..., 6), θ i, is measured about the z axis associated with the given joint using the right-hand rule. Note that the direction of rotation for each joint is indicated on the robot s body. All joint angles are zero in the configuration shown in Fig. 1. The mechanical limits of the robot s joints are as follows: 175 θ 1 175, 70 θ 2 90, 135 θ 3 70, 170 θ 4 170, 115 θ 5 115, 175 θ An input outside of these ranges will cause the robot to go into error mode. 2.4 Pose and Euler angles convention Some of Meca500 s commands take a pose (position and orientation of one reference frame with respect to another) as an input. In these commands, and in Meca500 s web interface, a pose consists of a Cartesian position, {x, y, z}, and an orientation specified in Euler angles, {α, β, γ}, according to the mobile XYZ convention. In this convention, if the orientation of Page 2 of 36 Copyright c 2017 by Mecademic Inc.

9 (a) rotation of 45 about the x axis (b) rotation of 90 about the new y axis (c) rotation of 90 about the new z axis Figure 2: Example showing the three consecutive rotations associated with the Euler angles {45, 90, 90 }. a second frame with respect to a first frame is described by the Euler angles {α, β, γ}, it means that if you align a third frame with the first one, then rotate this third frame about its x axis by α degrees, then about its y axis by β degrees, and finally about its z axis by γ degrees, the orientation of the third frame will be the same as that of the second one. An example of specifying orientation using the mobile XYZ Euler angle convention is shown in Fig. 2. In the third image of this figure, the orientation of the black reference frame with respect to the gray reference frame is represented with the Euler angles {45, 90, 90 }. 2.5 Joint set and robot position As we will mention later, for a given pose of the robot end-effector with respect to the robot s base, there are several possible solutions for the six values of the joint angles, i.e., several possible sets {θ 1, θ 2, θ 3, θ 4, θ 5, θ 6 }. It is therefore very important to have a specific term for a set of joint values. We will use the term joint set. For example, in Fig. 1, the joint set of the robot is {0, 0 0, 0 0, 0 }. A joint set defines completely the arrangement of the robot s links, which we will call the robot position. Do not confuse this term with the position of the robot s TCP. Similarly, a robot position can also be defined with the pose of the TRF with respect to the WRF, the definitions of both frames, and the configuration type (to be discussed in Section 3.3). The term robot position is a generic term referring to the arrangement of the robot s links. There is no direct answer to the question What is the current robot s position?. The right question to ask is What is the current joint set? or What is the current pose of the Copyright c 2017 by Mecademic Inc. Page 3 of 36

10 TRF with respect to the WRF, and the current configuration?. The term robot position will only be used to refer to the arrangement of the robot s links, as in the phrase: The current robot position is singular. 2.6 Units At Mecademic, we use the International System of Units. All distance units that are displayed to or entered by the user are in millimeters (mm), and all angles in degrees ( ). 3 Key concepts 3.1 Homing Homing is the process in which the joints of the Meca500 will find and travel to their zero positions. This so-called home position is shown in Fig. 1. While homing, it is critical that there are no obstacles present that could hinder the robot s movement. The robot s base must be installed on a horizontal surface free of vibration and movement. Furthermore, joint 4 must be within the range ±90. The robot s joints will move in a very specific order. First, joints 1, 2, and 3 will rotate simultaneously and go close to their zero positions. Next, they will rotate simultaneously in their positive senses up to about 3, and then go exactly to their zero positions (simultaneously again). Next, the same procedure will be applied to joints 4 and 5, but the small rotations will be up to about 7. Finally, joint 6 will rotate in the positive sense until it reaches its upper mechanical limit (i.e., up to 350 ), and then travel directly to its zero position. This automatic process may take up to one minute to execute. If your robot is equipped with Mecademic s gripper, the robot controller will automatically detect it, and the homing process will end with a homing of the gripper. Once joint six has been homed, the gripper will fully open, then fully close. Make sure there is nothing that restricts the full 6-mm range of motion of the gripper, while the latter is being homed. 3.2 Cornering All multi-purpose industrial robots function in a similar manner when it comes to moving around. You either ask the robot to move to a certain pose to to a certain joint set. When your target is a joint set, you have no control over the path that the robot will follow. When the target is a pose, you can either leave it to the robot to choose the path or require that the TCP follows a linear path. Thus, if you need to follow a complex curve (as in a gluing Page 4 of 36 Copyright c 2017 by Mecademic Inc.

11 application), you need to decompose your curve into multiple linear segments. Then instead of having the robot stop at the end of each segment and make a sharp change in direction, you can blend these segments using what we call cornering. Cornering is a feature that allows Meca500 s trajectory planner to keep the Cartesian velocity of the robot s end-effector constant between two TCP paths in a queue. When cornering is enabled, the trajectory planner will transition between the two trajectories using a rounded curve. The higher the speed, the more rounded the transition will be. Figure 3 shows an example of cornering. When cornering is disabled, each path will begin with an acceleration and end with a deceleration. Cornering is enabled by default. Cornering can be activated or deactivated with the SetCornering command. Figure 3: TCP path between two consecutive movements (in this case, two MoveLin commands). In blue, the cornering is disabled. In gray, it is enabled. 3.3 Inverse kinematic configuration Like virtually all six-axis industrial robot arms available on the market, Meca500 s inverse kinematics generally provide up to eight feasible joint sets for a desired pose of the TRF with respect to the WRF. Each of these solutions is associated with one of eight so-called configuration types, or configurations, defined by three parameters: c 1, c 3 and c 5. Each parameter corresponds to a specific geometric condition on the robot position: c 1 : c1 = 1, if the wrist center (i.e., the intersection point of the axes of joints 4, 5 and 6) is on the positive side of the yz plane of the frame associated with joint 2. This frame is obtained by shifting the BRF upwards and rotating it about the axis of joint 1 at θ 1 degrees. (This condition is often referred to as front ). c 1 = 1, if the wrist center is on the negative side of this plane ( back condition). c 3 : c3 = 1, if θ 3 > tan 1 (19/60) ( elbow up condition) c 3 = 1, if θ 3 < tan 1 (19/60) ( elbow down condition) c 5 : c5 = 1, if θ 5 > 0 ( no flip condition) c 5 = 1, if θ 5 < 0 ( flip condition) Copyright c 2017 by Mecademic Inc. Page 5 of 36

12 Figure 4 shows an example of each inverse kinematics configuration parameter, as well as of the limit conditions, which are called singularities. If you want to record your current robot position (e.g., after jogging the robot), you can choose between two possible approaches. One approach is to save directly the current joint set by retrieving it first with GetJoints. In this way, you don t have to worry about configurations. However, you won t be able to move the robot to this robot position by forcing the TCP to follow a straight line (i.e., use the MoveLin or MoveLinDelta commands). For example, if the recorded joint set corresponds to the robot holding a pin inserted in a hole, you won t be able to retrieve the pin following a linear path. Therefore, if you want to follow a linear path to or from a given target robot position, you must follow a different approach. You must record the corresponding pose of the TRF (by retrieving it with GetPose) with respect to the WRF, but also the corresponding configuration. Then, when you later want to approach this robot position with MoveLin from a starting robot position, you need to make sure the robot is already in this configuration. For example, you can set the desired configuration (using SetConf) and use MovePose to get to the starting robot position. Then, you can use MoveLin to get to the target robot position. Of course, you also need to use the same TRF and WRF. In most cases, however, you can enable the automatic configuration selection feature (using AutoConf) and not worry about configurations. (In fact, this feature is activated by default.) For example, if you simply want the TRF to go to a certain pose (as in inspection) you can use the command MovePose and the robot will automatically select the optimal configuration for this pose (the one that corresponds to the robot position that is faster to reach). As another example, consider that you have reached a certain robot position without knowing the configuration (e.g., by using the MoveJoints command). From there, you want to make an incremental linear motion using the command MoveLinDelta while keeping the same configuration. Again, enabling the automatic configuration selection feature will be the simplest solution. In this, case the robot does not select a new configuration (it is impossible to change the configuration while moving in linear mode); it rather ignores the desired configuration set with the SetConf command. Note again that even after enabling the automatic configuration selection, you will still not be able to change configurations while following a linear path (using the MoveLin or MoveLinDelta commands). This is because a change of configuration can only be accomplished by passing through a so-called singularity. In general, this is physically impossible while having the TCP follow a specific path (as is the case with the MoveLin and MoveLinDelta commands). Page 6 of 36 Copyright c 2017 by Mecademic Inc.

13 (a) c 1 = 1, back (b) shoulder singularity (c) c 1 = 1, front (d) c 3 = 1, elbow down (e) elbow singularity (f) c 3 = 1, elbow up (g) c 5 = 1, flip (h) wrist singularity (i) c 5 = 1, no flip Figure 4: Examples of the inverse kinematic configuration parameters and of the three types of singularities Copyright c 2017 by Mecademic Inc. Page 7 of 36

14 (a) {1, 1, 1} (b) {1, 1, 1} (c) {1, 1, 1} (d) {1, 1, 1} (e) { 1, 1, 1} (f) { 1, 1, 1} (g) { 1, 1, 1} (h) { 1, 1, 1} Figure 5: Example showing all eight possible configurations {c 1, c 3, c 5 } for the pose {77 mm, 210 mm, 300 mm, 103 mm, 36, 175 } of the FRF with respect to the BRF. 3.4 Workspace and singularities Many users mistakenly oversimplify the workspace of a six-axis robot arm as a sphere of radius equal to the reach of the robot (the maximum distance between the axis of joint 1 and the center of the wrist). The truth is that the Cartesian workspace of a six-axis industrial robot is a six-dimensional entity: the set of all attainable end-effector poses. Worse yet, as we saw in the preceding section, for a given end-effector pose, we can generally have eight different robot positions (Fig. 5). Thus, the Cartesian workspace of a six-axis robot arm is the combination of eight workspace subsets, one for each the eight configuration types. These eight workspace subsets have common parts, but there are also parts that belong to only one subset (i.e, there are end-effector poses accessible with only one configuration, because of joint limits). Therefore, in order to make optimal use of all attainable end-effector poses, the robot must often pass from one subset to the other. These passages are called singularities, and are very problematic when the robot s end-effector is to follow a specific Cartesian path (e.g., a line). Page 8 of 36 Copyright c 2017 by Mecademic Inc.

15 Any six-axis industrial robot arm has singularities. However, the huge advantage of robot arms like the Meca500, where the axes of the last three joints intersect at one point (the center of the robot wrist), is that these singularities are very easy to describe geometrically (see Fig. 4). In other words, it is very easy to know whether a robot position is close to singularity in the case of the Meca500. In a singular robot position, some of the maximum eight joint sets corresponding to the pose of the TRF may coincide, or there may be infinitely many joint sets. The problem with singularities is that at a singular position, the robot end-effector may not move in certain directions. This is a physical blockage, not a controller problem. Thus, singularities are one type of workspace boundary (the other type occurs when a joint is at its limit). For simplicity, think of two separate 3D volumes connected only with a 2D curve. For example, consider the Meca500 at its home position (Fig. 1). At this robot position, the end-effector cannot be moved laterally (i.e., along the y axis of the BRF); it is physically blocked. Thus, singularities are not some kind of purely mathematical problem. They represent actual physical limits. That said, because of the way the robot controller is programmed, at a singular position (or at a robot position very close to a singularity), the robot cannot be moved in any direction using a Cartesian move command such as MoveLin. There are three types of singular robots positions, and these correspond to the conditions under which the configuration parameters c 1, c 3 and c 5 are not defined. The most common singular position is called wrist singularity and occurs when θ 5 = 0 (Fig. 4h). In this singularity, joints 5 and 6 can rotate in opposite directions at equal velocities while the endeffector remains stationary. You will run into this singularity very frequently. The second type of singularity is called elbow singularity (Fig. 4e). It occurs when the arm is fully stretched, i.e., when the wrist center is in one plane with the axes of joints 2 and 3. In the Meca500, this singularity occurs when θ 3 = tan 1 (60/19) You will run into this singularity when you try to reach poses that are two far from the robot base. The third type of singularity is called shoulder singularity (Fig. 4b). It occurs when the center of the robot wrist lies on the axis of joint 1. You will run into this singularity when you work too close to the axis of joint 1. You can never pass through a singularity using the commands MoveLin or MoveLinDelta. However, you have no problems with singularities when using the commands MoveJoints, MoveJointsDelta or, to a certain extent, MovePose. Finally, you need to know that when using the commands MoveLin or MoveLinDelta, problems occur not only when crossing a singularity, but also when passing too close to a singularity. When passing close to a wrist or shoulder singularity, some joints will move very fast (i.e., 4 and 5, in the case of a wrist singularity, and 1, 4 and 5, in the case of a shoulder singularity), even though the TCP speed is very low. Thus, you must avoid moving in the vicinity of singularities in linear mode. Copyright c 2017 by Mecademic Inc. Page 9 of 36

16 4 Communication protocol 4.1 General information Generally, to operate the Meca500, the robot must be connected to a computer or a PLC over Ethernet. Commands may be sent through Mecademic s web interface, or through a custom computer program. The Meca500 communicates using null-terminated ASCII strings, which are transmitted over TCP/IP. The robot s default IP address is , and its default TCP/IP port is This port is referred to as the control port. Additionally, after homing, the robot will continuously send pose feedback over TCP/IP port Commands The Meca500 can interpret two kinds of commands: motion commands and request commands. Note that all commands must end with a NULL character. Commands are not case-sensitive. However, no whitespace is permitted before or after a command; only inside the arguments part. Empty lines are not permitted either Motion commands Motion commands are used to construct a trajectory for the robot. When the Meca500 receives a motion command, it places it in a queue. The command will be run once all preceding commands have been executed. The arguments for all motion commands, except AutoConf, SetConf, SetMoveLinDeltaRef and SetCornering, are IEEE-754 floating-point numbers, separated with commas and, optionally, spaces. The list of motion commands are presented in Section Request commands Request commands are used mainly to get status updates from the robot. Once received, the robot will immediately execute the command (e.g., return the requested information). For example, if you send a MoveLin command, followed by a GetPose command, you will not get the final pose of the TRF but an intermediate one. To get the end pose, you need to make sure that the robot has finished its movement, before sending the GetPose command. While some of these request commands make the robot move or stop (e.g., StartProgram or PauseMotion), request commands do not have a lasting effect on subsequent motions. The complete list of request commands are presented in Section 6. The format of the robot s response is summarized in Section 8.2. Page 10 of 36 Copyright c 2017 by Mecademic Inc.

17 4.3 Responses The Meca500 sends responses (also referred to as messages) when it encounters an error, when it receives a request command, and when its status changes. All responses from the Meca500 consist of an ASCII string in the following format: [4-digit code][message string OR return values.] The four-digit code indicates the type of the response: [1000] to [1999]: Error message due to a command [2000] to [2999]: Response to a command [3000] to [3999]: Status update message or general error The second part of an error message [1xxx] or status update message [3xxx] will always be a string describing the error or status change. The only exceptions are the messages [3007] and [3010], which contain a joint set and a pose, respectively. The second part of a command response [2xxx] may be a string, or a set of comma-separated return values, depending on the command. All message strings are intended to communicate information to the user, and are subject to change at any time. Therefore, parsing the message strings with custom software is not recommended. However, the comma-separated return value formats will not change without notification. Return values are either integers, or IEEE-754 floating-point numbers with three decimal places of precision Joints and pose feedback The Meca500 is configured to continuously send position feedback over the TCP/IP port Two kinds of feedback messages are sent over this port: joint feedback and pose feedback. Joint feedback returns the angles of the robot s joints (i.e., joint set). Pose feedback returns the pose of the TRF with respect to the WRF. These two types of feedback can also be enabled on port using the commands ActivateJointsFeedand ActivatePoseFeed respectively. Note that these commands only impact the messages on port Feedback messages are sent approximately every 15 ms. The format of the responses for the joints and the pose feedback is, respectively [3007][θ 1, θ 2, θ 3, θ 4, θ 5, θ 6 ] [3010][x, y, z, α, β, γ] Copyright c 2017 by Mecademic Inc. Page 11 of 36

18 5 Motion commands In the following, the motion commands are presented in alphabetical order. All motion commands have arguments, but not all have default values (e.g., the command Delay). Finally, only special responses are listed, since most motion commands may also generate [3004][End of movement.] and/or [3012][End of block.] messages (see SetEOB and SetEOM). 5.1 Delay(t) This command is used to add a time delay between two robot movements. In other words, the robot finishes all the movements sent before the Delay command and stops temporarily. (In contrast, the PauseMotion command interrupts the motion as soon as received by the robot.) Arguments: - t: desired pause length in seconds 5.2 Gripper(e) This command is used to open or close the gripper. The gripper will move its fingers until the grip force reaches 40 N. In the near future, it will be possible to reduce this force limit with a command. You can, however, control the speed of the gripper with the SetGripperVel command. The Gripper command acts like a robot motion command, being executed only after the preceding motion command has been completed. Currently, however, if a robot motion command is sent after the Gripper command, the robot will start executing the motion command without waiting for the gripper to finish its action. You must therefore send a Delay command after the Gripper command. Arguments: - e: open (1) or close (0) the gripper 5.3 MoveJoints(θ 1, θ 2, θ 3, θ 4, θ 5, θ 6 ) This command makes the robot move simultaneously its joints to the specified joint set. All joint rotations start and stop simultaneously The path that the robot takes is linear in the joint space, but nonlinear in the Cartesian space. Therefore, the TCP path is not easily predictable (Fig. 6). With MoveJoints, the robot can cross singularities without a problem. Page 12 of 36 Copyright c 2017 by Mecademic Inc.

19 Figure 6: End-effector motion when using the MoveJoints or MovePose commands Arguments: - θ i : the angle of joint i, where i = 1, 2,..., 6, in degrees [1007][Joint over limit. - Command: "..."] 5.4 MoveJointsDelta( θ 1, θ 2, θ 3, θ 4, θ 5, θ 6 ) This command is similar to the MoveJoints command. However, instead of using absolute values for the joint angles, the command takes relative values (negative or positive). The command is intended for jogging the robot in joint mode from a custom-made HMI, Arguments: - θ i : the increment value for joint i, in degrees, positive or negative, where i = 1, 2,..., 6 Note that, currently, only one argument can be non-zero. Unlike the MoveJoints command, this command generates no response, even if the desired motion is out of limits. Furthermore, if the desired motion is out of limits, the robot will not go into error mode, contrary to when using the MoveJoints command. 5.5 MoveLin(x, y, z, α, β, γ) This command makes the robot move its TRF to a specific pose with respect to the WRF while keeping the TCP along a linear path in Cartesian space, as illustrated in Fig. 7. If the final (desired) orientation of the TRF is different than the initial orientation, the orientation will be modified along the path using SLERP interpolation. Copyright c 2017 by Mecademic Inc. Page 13 of 36

20 Figure 7: The TCP path when using the MoveLin command Using this command, the robot cannot move to or through a singularity. This command cannot automatically change the robot s configuration. Arguments: - x, y, and z: the coordinates of the origin of the TRF w.r.t. the WRF, in mm - α, β, and γ: the Euler angles representing the orientation of the TRF w.r.t. the WRF, in degrees 5.6 MoveLinDelta( x, y, z, α, β, γ) This command is somewhat similar to the MoveLin command, but instead of absolute Cartesian coordinates, it takes increments as input. It is mainly intended for jogging the robot in Cartesian mode, but could also be very useful for small relative displacements with respect to the TRF or WRF, depending on what was set with the SetMoveLinDeltaRef(n) command. Arguments: - x, y, and z: the distance (in mm) the robot s TCP must travel along an axis parallel to the x, y or z axis of the TRF or WRF - α, β, and γ: the angle (in degrees) at which the robot s end-effector must rotate about an axis passing through the TCP and parallel to the x, y or z axis of the TRF or WRF Note that, currently, only one argument can be non-zero. [3011][Cartesian jogging stopped because of a singularity.] [3019][Cartesian jogging will be stopped because of workspace limit.] Page 14 of 36 Copyright c 2017 by Mecademic Inc.

21 If the MoveLinDelta command requires that the robot passes too close to a singularity, it will not be executed and the robot will send the first message. If the command is impossible to execute because of workspace limits, the robot will send the second message. In both cases, the robot will not go into error mode, contrary to when using the MoveLin command. 5.7 MovePose(x, y, z, α, β, γ) This command makes the robot move its TRF to a specific pose with respect to the WRF. All joint rotations start and stop at the same time. The path the robot takes is linear in the joint-space, but nonlinear in Cartesian space. Therefore, the path the TCPwill take to its destination is not easily predictable, as illustrated in Fig. 6. Using this command, the robot has no problem crossing a singularity, as long as AutoConf is enabled, or starting from a singular robot position. However, currently, the robot cannot go to a pose for which one of the possible robot positions is singular. Arguments: - x, y, and z: the coordinates of the origin of the TRF w.r.t. the WRF, in mm - α, β, and γ: the Euler angles representing the orientation of the TRF w.r.t. the WRF, in degrees 5.8 AutoConf(e) This command enables or disables the robot s automatic configuration selection. This feature allows the MovePose command to pass from one robot s inverse kinematic configuration to another. The command MoveLin cannot trigger a configuration change. To do so, the robot will have to pass through a singularity, while displacing its TCP along a linear path with constant velocity. In general, this is physically impossible. However, enabling AutoConf, allows you to execute the MoveLin and MoveLinDelta commands, regardless of the current configuration. In other words, the AutoConf can also be interpreted as a request to ignore the desired configuration defined with the SetConf command. Note that this command will be renamed SetAutoConf in the next robot firmware. Furthermore, you will no longer be able to disable the automatic configuration selection in a singular robot position. Arguments: - e: enable (1) or disable (0) automatic configuration selection Copyright c 2017 by Mecademic Inc. Page 15 of 36

22 Default values: AutoConf is enabled by default. If you disable it, the new desired inverse kinematic configuration will be the one corresponding to the current robot position. [2034][The robot configuration will be automatically chosen.] [2035][The robot configuration won t be automatically chosen.] Note: This command will be renamed to SetAutoConf in the next version of the robot firmware. 5.9 SetCartVel(v) This command limits the Cartesian linear velocity of the robot s TRF with respect to its WRF. It only affects the movements generated by the MoveLin command. Arguments: - v: TCP velocity limit, ranging from 1 mm/s to 500 mm/s Default values: The default TCP velocity limit is 200 mm/s. [2020][TCP velocity modified.] 5.10 SetConf(c 1, c 3, c 5 ) This command sets the desired robot s inverse kinematic configuration to be observed in the MovePose, MoveLin and MoveLinDelta commands. The robot s inverse kinematic configuration (see Fig. 4) can be automatically selected by using the AutoConf command. Using SetConf automatically disables the automatic configuration selection. Arguments: - c 1 : first inverse kinematics configuration parameter, either 1 or 1 - c 3 : second inverse kinematics configuration parameter, either 1 or 1 - c 5 : third inverse kinematics configuration parameter, either 1 or 1 Default values: The default desired configuration is c 1 = 1, c 3 = 1, c 5 = 1. Note, however, that this Page 16 of 36 Copyright c 2017 by Mecademic Inc.

23 default value has no raison d être other than to be returned when requested by the GetConf command, before having disabled the automatic configuration selection. This is because the automatic configuration selection feature is activated by default. To deactivate it, you need to either specify a desired configuration with the SetConf command, or simply disable the feature with AutoConf(0), in which case the new desired configuration will be the one corresponding to the current robot position. [2028][The desired robot configuration is set to c 1 /c 3 /c 5.] 5.11 SetCornering(e) This command enables/disables the robot s cornering feature. Note that the commands MoveLin, MovePose, and MoveJoints will only send [3004][End of movement.] responses when the robot comes to a complete stop and the command SetEOM(1) was used. Therefore, enabling cornering may suppress these responses. Arguments: - e: enable (1) or disable (0) cornering Default values: Cornering is enabled by default. [2032][The cornering is enabled.] [2033][The cornering is disabled.] 5.12 SetGripperForce(f) This command limits the grip force of the gripper. Arguments: - f: grip force limit, ranging from 0 to 100% (i.e., approximately 40 N) Default values: By default, the grip force limit is 50%. [2077][Gripper force modified.] [1035][Gripper force over limit. - Command: "..."] Copyright c 2017 by Mecademic Inc. Page 17 of 36

24 5.13 SetGripperVel(v) This command limits the velocity of the gripper fingers (with respect to the gripper). Arguments: - v: finger velocity limit, ranging from 2 to 95 mm/s Default values: By default, the finger velocity limit is 50 mm/s. [2078][Gripper velocity modified.] [1036][Gripper velocity over limit. - Command: "..."] 5.14 SetJointVel(ω) This command limits the angular velocities of the robot s joints. The velocity limit for joints 1, 2, and 3 will be ω, while the velocity limit for joints 4, 5, and 6 will be 2ω. This command only affects the movements generated by the MovePose and MoveJoints commands. Arguments: - ω: angular velocity limit for joints 1, 2, and 3, ranging from 1 /s to 135 /s Default values: By default, the angular velocity limit for joints 1, 2 and 3 is 45 /s. [2022][Joint velocities modified.] 5.15 SetMoveLinDeltaRef(n) This command sets the reference frame, WRF or TRF, to be used in the MoveLinDelta command. Arguments: - n: desired moving reference frame (0 for WRF, 1 for TRF) Default values: The default reference frame is the WRF. Page 18 of 36 Copyright c 2017 by Mecademic Inc.

25 [2067][MoveLinDelta reference is WRF.] [2068][MoveLinDelta reference is TRF.] 5.16 SetTRF(x, y, z, α, β, γ) This command defines the pose of the TRF with respect to the FRF. Arguments: - x, y, and z: the coordinates of the origin of the TRF w.r.t. the FRF, in mm - α, β, and γ: the Euler angles representing the orientation of the TRF w.r.t. the FRF, in degrees Default values: By default, the TRF coincides with the FRF. [2024][New TRF defined.] 5.17 SetWRF(x, y, z, α, β, γ) This command defines the pose of the WRF with respect to the BRF. Arguments: - x, y, and z: the coordinates of the origin of the WRF w.r.t. the BRF, in mm - α, β, and γ: the Euler angles representing the orientation of the WRF w.r.t. the BRF, in degrees Default values: By default, the WRF coincides with the BRF. [2025][New WRF defined.] 6 Request commands In the following, the request commands are presented in alphabetical order. Most request commands do not have arguments. Copyright c 2017 by Mecademic Inc. Page 19 of 36

26 6.1 ActivateJointsFeed This command activates the joints feed on port [2040][Automatic joints feed is enabled.] 6.2 ActivatePoseFeed This command activates the pose feed on port [2038][Automatic pose feed is enabled.] 6.3 ActivateRobot This command activates all motors and disables the brakes on joints 1, 2, and 3. It must be sent before homing is started. This command only works if the robot is idle. [2000][Motors activated.] [2001][Motors already activated.] The first response is generated if the robot was not active, while the second one is generated if the robot was already active. 6.4 ActivateSim The Meca500 supports a simulation mode in which all of the robot s hardware functions normally, but none of the motors move. This mode allows you to test programs with the robot s hardware (i.e., hardware-in-the-loop simulation), without the risk of damaging the robot or its surroundings. Simulation mode can be activated and deactivated with the ActivateSim and DeactivateSim commands. [2045][The simulation mode is enabled.] 6.5 ClearJogMotion This command is only necessary when using MoveJointsDelta or MoveLinDelta for jogging in your own HMI. It immediately stops the robot and clears the current jog motion. Page 20 of 36 Copyright c 2017 by Mecademic Inc.

27 [2044][The motion was cleared.] 6.6 ClearMotion This command stops the robot s movement, in the same fashion as the PauseMotion command (i.e., by decelerating). However, if the robot is stopped in the middle of a trajectory, the rest of the trajectory is deleted. Furthermore, the robot is immediately ready to receive and execute new motion commands. You don t need to use the PauseMotion command prior to using the ClearMotion command. [2044][The motion was cleared.] 6.7 DeactivateJointsFeed This command deactivates the joints feed on port [2041][Automatic joints feed is disabled.] 6.8 DeactivatePoseFeed This command deactivates the pose feed on port [2039][Automatic pose feed is disabled.] 6.9 DeactivateRobot This command disables all motors and engages the brakes on joints 1, 2, and 3. It must not be sent while the robot is moving. Deactivating the robot while in motion could damage the joints. This command should be run before powering down the robot. When this command is executed, the robot loses its homing. The homing process must be repeated after reactivating the robot. [2004][Motors deactivated.] Copyright c 2017 by Mecademic Inc. Page 21 of 36

28 6.10 DeactivateSim This command deactivates the simulation mode. See the description of the ActivateSim command, for an overview of Meca500 s simulation mode. [2046][The simulation mode is disabled.] 6.11 DisableBrakes This command disables the brakes of the robot, if and only if the robot is powered but deactivated. The command returns no message. [2008][All brakes released.] 6.12 EnableBrakes This command enables the brakes of the robot. The command returns no message. [2010][All brakes set.] 6.13 GetAutoConf This command returns the current status of the robot s automatic configuration selection feature, enabled/disabled by the AutoConf command. [2034][The robot configuration will be automatically chosen.] [2035][The robot configuration won t be automatically chosen.] 6.14 GetCartVel This command returns the desired maximum linear velocity (in mm/s) of the robot s TCP for the MoveLin command. The value is set by the SetCartVel command (or 500 mm/s, by default). [2019][V xyz ] Page 22 of 36 Copyright c 2017 by Mecademic Inc.

29 6.15 GetConf This command returns the robot s desired inverse kinematic configuration (see Fig. 4). This is the configuration set by the SetConf command. Note that in the next robot firmware, there will be another command which will return the configuration of the current robot position. Furthermore, there will be specific messages when the robot position is singular or too close to being singular. [2029][c 1, c 3, c 5 ] - c 1 : first inverse kinematic configuration parameter, either 1 or 1 - c 3 : second inverse kinematic configuration parameter, either 1 or 1 - c 5 : third inverse kinematic configuration parameter, either 1 or GetCornering This command returns the status of the cornering mode, as defined by the SetCornering command. [2032][The cornering is enabled.] [2033][The cornering is disabled.] 6.17 GetJoints This command returns the robot s joint angles in degrees. [2026][θ 1, θ 2, θ 3, θ 4, θ 5, θ 6 ] - θ i : the angle of joint i, in degrees, where i = 1, 2,..., GetJointVel This command returns the desired maximum velocity of joint 1, 2 and 3 (in /s), set by the SetJointVel command (or 135 /s, by default). The maximum velocity of joints 4, 5 and 6 is twice higher. [2018][V θ ] Copyright c 2017 by Mecademic Inc. Page 23 of 36

30 6.19 GetMotionStatus This command returns the current status of motion, as defined by the PauseMotion or ResumeMotion commands. [2042][Motion paused.] [2043][Motion resumed.] 6.20 GetMoveLinDeltaRef This command returns the current reference frame used by the MoveLinDelta command (TRF or WRF). [2068][MoveLinDelta reference is TRF.] [2067][MoveLinDelta reference is WRF.] 6.21 GetPose This command returns the current pose of the robot s TRF with respect to the WRF. [2027][x, y, z, α, β, γ] - x, y, and z: the coordinates of the origin of the TRF w.r.t. the WRF, in mm; - α, β, and γ: the Euler angles representing the orientation of the TRF w.r.t. the WRF, in degrees GetSimulationMode This command returns the current status of simulation, as defined by the ActivateSim or DeactivateSim commands. If the robot is activated, the robot will return a warning that simulation mode can only be enabled or disabled while the robot is deactivated. [2045][The simulation mode is enabled.] [2046][The simulation mode is disabled.] Page 24 of 36 Copyright c 2017 by Mecademic Inc.

31 6.23 GetStatusRobot This command returns the robot s status. [2007][a, h, j, e, p, eob, eom] - a: motor operation state (0 for inactive, 1 for active) - h: homing state (0 for homing not performed, 1 for homing performed) - j: joint feed status (0 for joint feed disabled, 1 for joint feed enabled) - e: error status (0 for robot not in error mode, 1 for robot in error mode) - p: pose feed status (0 for pose feed disabled, 1 for pose feed enabled) - eob: end of block status (0 for end of block disabled, 1 for end of block enabled) - eom: end of movement status (0 for end of movement disabled, 1 for end of movement enabled) 6.24 GetGripperStatus This command returns the gripper s status. [2079][g, h, p, l, e, o] - g: gripper enabled, i.e., present (0 for disabled, 1 for enabled) - h: homing done (0 for homing not performed, 1 for homing performed) - p: holding part (0 if the gripper does not hold a part, 1 otherwise) - l: limit reached (0 if the fingers are not fully open or closed, 1 otherwise) - e: general error (0 for absence of error, 1 for presence of error) - o: overload (0 if there is no over load, 1 if the gripper is in force over load) 6.25 GetTRF This command return the defined pose of the TRF with respect to the FRF. [2014][x, y, z, α, β, γ] - x, y, and z: the coordinates of the origin of the TRF w.r.t. the FRF, in mm; - α, β, and γ: the Euler angles representing the orientation of the TRF w.r.t. the FRF, in degrees. Copyright c 2017 by Mecademic Inc. Page 25 of 36

32 6.26 GetWRF This command return the defined pose of the WRF with respect to the FRF. [2013][x, y, z, α, β, γ] - x, y, and z: the coordinates of the origin of the WRF w.r.t. the BRF, in mm; - α, β, and γ: the Euler angles representing the orientation of the WRF w.r.t. the BRF, in degrees Home This command starts the robot and gripper homing process (Section 3.1). While homing, it is critical to remove any obstacles that could hinder the robot and gripper movements. The robot must be installed on a level surface with no vibrations. This command may take up to one minute to execute. [2002][Homing done.] [2003][Homing already done.] [1014][Homing failed. - Command: "..."]. The first response is sent if homing was completed successfully, while the second one is sent if the robot is already homed. The third response is sent if the homing procedure failed PauseMotion This command stops the robot s movement. The command is executed as soon as received (within approximately 5 ms from it being sent, depending on your network configuration), but the robot stops by decelerating, and not by applying the brakes. For example, if a MoveLin command is currently being executed when the PauseMotion command is received, the robot s TCP will stop somewhere along the linear path. If you want to know where exactly did the robot stop, you can use the GetPose or GetJoints commands. Strictly speaking, the PauseMotion command pauses the robot s motion; the rest of the trajectory is not deleted and can be resumed with the ResumeMotion command. The PauseMotion command is useful if you develop your own HMI and need to implement a pause button. It can also be useful if you suddenly have a problem with your tool (e.g., while the robot is applying an adhesive, the reservoir becomes empty). Page 26 of 36 Copyright c 2017 by Mecademic Inc.

33 The PauseMotion command normally generates the following two responses. The first one is always sent, whereas the second one is sent only if the robot was moving when it received the PauseMotion command. Finally, if a motion error occurs while the robot is at pause (e.g., if another moving body hits the robot), the motion is cleared and can no longer be resumed. [2042][Motion paused.] [3004][End of movement.] 6.29 ResetError This command resets the robot s error status. The command can generate one of the following two responses. The first response is generated if the robot was indeed in an error mode, while the second one is sent if the robot was not in error mode. [2005][The error was reset.] [2006][There was no error to reset.] 6.30 ResumeMotion This command resumes the robot s movement, if it was previously paused with the command PauseMotion. More precisely, the robot s TCP resumes the rest of the trajectory from the pose where it was brought to a stop (after deceleration). This command will not work if the robot was deactivated after the last time the command PauseMotion was used, if the robot is in an error mode, or if the rest of the trajectory was deleted using the ClearMotion command. Note that it is not possible to pause the motion along a trajectory, have the end-effector move away, then have it come back, and finally resume the trajectory. If you send motion commands while the robot is paused, they will simply be placed in the queue. [2043][Motion resumed.] Copyright c 2017 by Mecademic Inc. Page 27 of 36

34 6.31 SetEOB(e) When the robot finishes its movements, it can send the message [3012][End of block.]. This means that there are no more motion commands in the queue and the robot s velocity is zero. The user could enable or disable this message by sending this command. Arguments: - e: enable (1) or disable (0) message Default values: By default, the end-of-block message is enabled. [2054][End of block is enabled.] [2055][End of block is disabled.] 6.32 SetEOM(e) The robot can also send the message [3004][End of movement.] velocity becomes zero. as soon as the robot s Arguments: - e: enable (1) or disable (0) message Default values: By default, the end-of-movement message is disabled. [2052][End of movement is enabled.] [2053][End of movement is disabled.] 6.33 SetOfflineProgramLoop(e) This command is used to define whether the program that is to be saved must later be executed a single time or infinitely many times. The command must be used immediately after using the StartSaving command. Arguments: - e: enable (1) or disable (0) the loop execution Default values: By default, looping is disabled. Page 28 of 36 Copyright c 2017 by Mecademic Inc.