KUKA driver and robot model issues- Printable Version +- RoboDK Forum (//m.sinclairbody.com/forum) +-- Forum: RoboDK (EN) (//m.sinclairbody.com/forum/Forum-RoboDK-EN) +--- Forum: RoboDK bugs (//m.sinclairbody.com/forum/Forum-RoboDK-bugs) +--- Thread: KUKA driver and robot model issues (/ Thread-KUKA-driver-and-robot-model-issues)

KUKA driver and robot model issues-kkos-09-22-2022 Hello, I am experiencing problems with controlling a KUKA KR 700 PA with RoboDK. My setup and issues are listed below. My setup: OS: Windows 10 Version: RoboDK 5.5.1 (Professional license) Robot:KUKA KR 700 PA(4-axis industrial palletizer) Controller: KRC5 RoboDK driver: downloaded via thispost, but had to fix RoboDKsync542.src (declarations were missing, see attachment "RoboDKsync542_MODIFIED.src") Station: contains only the manipulator from RoboDK library, no external axis or tool (see attachment "example.rdk") Base and tool frame are set to [0, 0, 0, 0, 0, 0], both in RoboDK and the controller The robot will be controlled in real-time by the Windows-PC and RoboDK (no offline programming) Issue 1: Invalid angles for axis A3 It seems like the RoboDK model of this robot is not set up correctly. Reasons for this assumption: When using "Get Position", the coordinates of the simulated robot differ from the actual coordinates (see attachment "get_position.jpg"). The joint angles are the same, but the position does not look the same. I am certain that our actual robot is installed correctly. When manually setting the actual coordinates in the simulation, the position matches the real robot, but the 3rd joint angle (A3) is different (see attachment "corrected_position.jpg"). Sending a position from RoboDK to the robot causes either a coordinate mismatch or, in some cases, valid coordinates set in the simulation cannot be reached by the real robot. I assume this is because not the coordinates, but the joint values (containing the invalid A3 joint) from the simulation are transferred to the controller. Issue 2: Joint values are not processed correctly by RoboDK Even though this robot only has 4 axes, 6 joint values are received from and sent to the controller (two of those are passive and cannot be controlled directly). Axis 4 and 5 are passive, 6 is the flange. It seems like RoboDK sets the value of axis 4 as the flange when receiving data, and the flange's value for axis 4 when sending data. To get to this conclusion, I checked the network traffic between RoboDK and the controller with WireShark. The following behaviour could be recorded: Get Position: RoboDK: requests position Controller: sends "{E6AXIS: A1 3.93568277, A2 -112.663696, A3 103.796738, A4 -2.35408331E-31, A5 98.8669586, A6 3.93568277, E1 0.0, E2 0.0, E3 0.0, E4 0.0, E5 0.0, E6 0.0}" RoboDK: sets joint values as "1: 3.93568277, 2: -112.663696, 3: 103.796738,4: -2.35408331E-31", whereas 4 should have the value of A6 (similiar results can be seen in attachment "get_position.jpg") Move Joints: RoboDK: move joints to HOME-position (coordinates: [2020, 0, 1900, -180, 0, -189]; angles: [0, -90, 90, 0] RoboDK: sends MOVEJ instruction with "COM_E6AXISI{A1 0.00000,A2 -90.00000,A3 90.00000,A4 0.00000,A5 2020.00000,A6 0.00000}", where it seems like A4 has been set to joint 4, and A5 and A6 have been set to X and Y of the targetcoordinates(maybe previously allocated memory is used?) Controller: moves the robot in HOME-position despite some invalid values (other positions might not be reachable by the robot and others will have mismatched coordinates, I haven't found the exact cause for this) Issue 3: MOVEL instructions are not sent to the controller To avoid sending joint values to the controller, I tried to send linear move instructions. These seem to not be processed at all, since theCOM_ACTION 3signal for triggering a linear move is never sent by RoboDK to the controller (also recorded with WireShark). RoboDK: run program on robot containing only linear move to HOME-position (see program "MOVEL" in .rdk-file) RoboDK: doesnotsend any instruction to controller RoboDK: program is finished (simulated robot did not move either, but path is shown) Issue 4: Unable to start apikuka.exe in console mode To find a solution to my issues, I tried to use the KUKA driver as console tool. After copying the missing Qt5Network.dll (taken from "RoboDK\bin") to "RoboDK\api\Robot", the program gives the following error: "The application was unable to start correctly (0xc000007b)." Unfortunately, the combination of issues 1-3 pose a severe problem for using RoboDK in this setup. I explored possible errors on my side, but was unable to find a solution. Help is very much appreciated. 再保险:KUKA driver and robot model issues-Albert-09-25-2022 Thank you for such a clear explanation of the issue. 它看起来像库卡基米-雷克南700 PA机器人模型not have the correct joint coupling in RoboDK. Can you confirm if the attached model solves the coupling problem? Did you change any default controller parameters to drive the joints? If not, we'll release a new official robot for this KUKA KR 700 PA robot model. Also, it looks like the robot has virtual axes 4 and 5 that should be ignored as they are calculated as a function of axes 2 and 3. Does that make sense? If not, it would be great to have a table of joint positions and their corresponding pose values. Or hopefully @Dmitryan help us troubleshoot this issue with the virtual KUKA robot. Once we fix issues 1 and 2 (hopefully with this new model), issue 3 should be fixed automatically. If you want to try the driver, you should copy the apikuka.exe file in C:/RoboDK/bin to be able to run it. On the other hand, Dmitry is working on an improved driver that has many new features. 再保险:KUKA driver and robot model issues-kkos-09-26-2022 Hello Albert, I can now use the apikuka.exe by itself, thanks for the tip. The attached robot model solves the issue of differing values for the third axis (A3). Now, when using "Get Position", the poses match with the exception of the flange rotation (A6). I noticed that the new model can be moved to invalid positions (see attached image). The problem of invalid values A4 to A6 still persists, I attached an excel file containing a comparison of actual vs. recorded coordinate and joint values. For clarification: "Actual" represents the values read from the controller's smartPad and "RoboDK (get)" describes the values shown in the RoboDK GUI when using "Get Position". "RoboDK (send)" is what has been sent in the TCP packet from RoboDK to the controller via "Move Joints" for the position that has just been retrieved. The positions can be viewed in the attached rdk-file. As mentioned before, it seems like RoboDK sends X and Y coordinates instead of A5 and A6 joint angles to the controller and sets the received A4 angle as the flange (A6). I believe it is necessary to process the entire array of A1-A6 in RoboDK, since the controller expects the passive joints to be set correctly. When sending positions from RoboDK to the controller, I noticed they mostly fail because a software limit switch is reached for A5. As for how A4 and A5 are calculated, I am unsure - hopefully the excel file can give you some insight. Since I did not change any joint parameters in the controller, you can go ahead and update the model. Thank you for help! 再保险:KUKA driver and robot model issues-kkos-09-26-2022 Quick update: I constructed my own model of the robot to which I added all 6 axes. Retrieving the position and sending joint move commands seems to work this way. Poses, coordinates and joint angles in RoboDK match the ones of the real robot (see attached images). Unfortunately it does not look complete and enables invalid positions and manipulation of the passive axes, but this is the only way I can control the robot as of now. If needed, I can send you the model via mail. 再保险:KUKA driver and robot model issues-Albert-09-28-2022 Thank you for such a detailed description of the problem. It was very helpful for us to solve this issue. @Dmitrysent you an email with the test driver and post processor fixing these issues. We also prepared a new installer for the new version of RoboDK (5.5.2) fixing these issues. You can download this version here: //m.sinclairbody.com/downloads/Install-RoboDK-64-v5.5.2.exe This version includes the following fixes: Updated KUKA post processor to work with KUKA PA robots Updated kukabridge driver that solves the issues you mentioned. In short, for palletizing KUKA robots, A4 is set to always 0 deg and A5 is calculated as 90-A2-A3. A6 is the real axis/motor 4. Also, we added the option to customize the allowed workspace for this palletizing robot (see attached image). Note that we don't have precise information about the allowed workspace. If you can share a datasheet we can help you improve it. Or you can customize the allowed workspace by double clicking joint limits for joints 2 or 3. I attached 2 models that improve the workspace: Updated KUKA KR-700 PA which works with the latest version of RoboDK (5.5.2 and later). Older KUKA KR-700 PA model which works with previous versions (version 5.5.1 or earlier). The only difference is that it does not have the link between the joint 2 and joint 4 in the 3D model. [attachment=3747] Let us know if you still have issues. 再保险:KUKA driver and robot model issues-kkos-09-29-2022 Thanks a lot for the update. I believe the kukabridge driver in the version you linked is outdated, I had to swap it with the latest version Dmitry sent me for it to work correctly (see problem regarding A4 and A6). The updated robot model does not have any of the issues mentioned above, thanks a lot!