Hi, guys. I am debugging a program to control KUKA robot based on JOpenShowVar. A position variable defined in $config.dat is set periodically by a client in the laptop. The robot controller retrieves the variable to get the target position. A problem is that when the client in the laptop stops setting the position variable, the robot can still run and change the target position for several seconds. The client and the controller communicate via TCP/IP. I wonder how the controller retrieves the position variable and if there is a congestion in the controller of KUKA. If there is congestion, how to avoid it? Can anybody give me some tips? Thanks.
Command congestion in the controller of KUKA?
-
Swift Tao -
October 16, 2016 at 12:44 PM -
Thread is marked as Resolved.
-
-
motion parameters (position, tool, base, speed, ipo mode...) and program controls (start/stop) have different functions. why would you rely on one to do job of another?
-
Are you sending the robot absolute positions, or relative positions? If relative, you need to keep in mind the Advance Run Pointer. There's also potential issued where the robot would keep applying "stale" data if communications was halted, unless you handle your garbage collection carefully on the robot end.
-
Are you sending the robot absolute positions, or relative positions? If relative, you need to keep in mind the Advance Run Pointer. There's also potential issued where the robot would keep applying "stale" data if communications was halted, unless you handle your garbage collection carefully on the robot end.I send absolute positions. It seems the robot will keep the last position when the communication was halted. When it runs again, the robot will first run to this "stale" position but the latest position. I don't know if there is any possibility to solve this on the controller end since the controller is not open to users.
-
How is your robot-side program structured? What you're describing doesn't make sense -- if an absolute position is sent to the robot, it's going to go to that position, and it's not going to go anywhere else until it receives new coordinates.
That said, if the PC sends a position and then loses communications, the robot is still going to complete the last motion command it received, unless you add additional KRL programming to handle that scenario. Which is not easy, but entirely feasible. -
How is your robot-side program structured? What you're describing doesn't make sense -- if an absolute position is sent to the robot, it's going to go to that position, and it's not going to go anywhere else until it receives new coordinates.
That said, if the PC sends a position and then loses communications, the robot is still going to complete the last motion command it received, unless you add additional KRL programming to handle that scenario. Which is not easy, but entirely feasible.On the robot-side, the program is as following to drive the robot to the position "MYAXIS". An application in the LAPTOP updates the value of "MYAXIS" periodically. The problem is that: when the application in the LAPTOP stops updating "MYAXIS", the robot moves to several different positions and then stops. It is desired that when the application in the LAPTOP stops updating "MYAXIS", the robot moves to just one position to complete the movement and then stops. Thanks.
Code on robot-side:
LOOP
LOCAL.A1 = MYAXIS.A1
LOCAL.A2 = MYAXIS.A2
LOCAL.A3 = MYAXIS.A3
LOCAL.A4 = MYAXIS.A4
LOCAL.A5 = MYAXIS.A5
LOCAL.A6 = MYAXIS.A6
PTP LOCAL C_PTP
ENDLOOP -
-
Thanks kr16_2. The command PTP_REL is capable to achieve the effect that I need.
-
If you want to use PTP_REL, you need to ensure that, if the Laptop stops sending values, the values of MYAXIS in the robot are set to 0. Otherwise, the robot will continue to apply the last received relative correction until it hits a limit (or an obstruction)
-
Good tips! Thanks.