Beckhoff TwinCAT application tutorial TwinCAT control Panasonic servo NC custom linear interpolation

For the joint motion of MOVEJ, our primary concern lies in the angle of each motor (considering coordinated motion initiation and completion across multiple motors). The key is to normalize the acceleration for each motor, ensuring synchronized start and stop. You may refer to the Introduction to Robotics for a more detailed explanation of this process.

It's crucial to follow the overall process of updating joint positions (MOVEJ) => updating TCP (forward kinematics) => updating joint and TCP velocities.

Since the forward kinematics solution is unique, it needs to be executed in every cycle of the main program. Of course, you have the option to place it within the MoveUpdate function. Regardless of the type of motion being executed, refreshing the forward kinematics once per cycle is advisable.

For the TCP motion with MOVEL, our focus is solely on the end-effector's position and orientation. The primary consideration is whether the end-effector can reach the target position. The key lies in inverse kinematics, where the inverse solution is computed. The joint positions corresponding to the inverse solution are then transmitted to the motors in each cycle, enabling end-effector motion with coordinated linkage across all axes. For more complex scenarios, you may refer to the Introduction to Robotics.

It's essential to follow the entire process of updating TCP position (MOVEL) => updating joint positions (inverse kinematics) => updating joint and TCP velocities.

Since inverse kinematics is not mandatory and is only executed during MOVEL, it is categorized under the same process as MOVEJ (MOVEUpdateDATA). Before updating the data, it's crucial to check whether joint positions and velocities exceed the limits.

For a two-axis linear module, it is relatively simple with only XY degrees of freedom and no involvement of orientation. However, the algorithm's process and significance remain the same. It is possible to incorporate monitoring to capture the smoothness of joint and TCP positions during start and stop. In this case, the arrays theRadius (representing device joint positions) and posRPYRadius (representing device TCP positions) are crucial.

The push buttons for jogging are mutually influential; JOG Joint affects TCP position, and JOG TCP affects joint position. In a linear module, each degree of freedom is independent. For instance, the X degree of freedom is solely controlled by the J1 motor. The motor's angle, accounting for factors like lead screws, guide rails, or gear reduction, can be proportionally mapped to millimeters. It is even possible to measure and derive simple conclusions.

J0: 36 cm => 72 radians -45 radians => 27 radians

J1: 40 cm => 80 radians -40 radians => 40 radians

Therefore, it can be simplistically considered that each joint movement of 1 radian corresponds to an X or 5mm offset for each module. Using radians for representation is more concise, as often the specific angle of the motor may not be of primary concern, but rather the resulting output displacement.

To fully grasp the concept of normalization, the point-to-point movements in both X and Y essentially boil down to a form of linear motion. For instance, moving in the positive X direction involves keeping the Y coordinate constant, setting a large value for X, and then executing linear motion. Whether it's jogging, returning to the origin, or entering a target position through a pop-up panel for subsequent movement, fundamentally, it is the same. The difference lies in the target position and the execution process, while the essence of the motion remains consistent.

Although it involves linear interpolation, there are still several considerations, especially during the startup process. One approach is to calculate isolated waypoints directly based on the given velocity and acceleration (effectively dividing the straight line into segments, with the requirement that the TCP reaches each isolated segment within each PLC cycle). Another method involves gradually increasing the step size of TCP during the startup process (akin to envisioning a sprinter accelerating over 100 meters, progressively getting faster until reaching the specified speed and then maintaining a constant speed).

Additionally, stopping can be approached in various ways. In the example provided, it simplifies by demonstrating only trapezoidal and S-shaped acceleration during deceleration. The stopping process adopts the joint stopping method from MOVEJ, so in essence, the end-effector TCP doesn't necessarily maintain a straight line when stopping. There is room for further optimization in handling the end-effector TCP during the stop phase.

For the sake of consistency between virtual and real modes, during the stopping phase, only the virtual joint positions and joint velocities are collected. These virtual variables could potentially represent real values if operating in real mode, where data is obtained directly from the actual drives. This unified approach ensures that the data collected during stopping is consistent regardless of whether the system is in virtual or real mode.

Due to the custom nature of the algorithm, it is not possible to directly retrieve information on whether the motion is complete from absolute motion modules. However, one can develop a custom module that continually checks if the current position is close to the target position during execution. For instance, considering proximity within a certain range as reaching the destination.

If there is a need to move back and forth between several points, it is necessary to wait for the completion of the previous motion before initiating the next one.

Finally, even though MOVEJ and MOVEL motion methods are defined, the trajectories plotted are fundamentally linear. This is due to the simple proportional relationship between joints and TCP. In robots with a serial pure rotational structure, MOVEJ traces irregular spatial arcs, while MOVEL maintains a linear TCP trajectory. Since MOVEJ does not involve inverse kinematics, it often yields smoother trajectories and better motor start-stop effects compared to MOVEL in most scenarios.