Robot moving to last position when switching back from teach to repeat

    Dear all,

    I'm experiencing a very annoying phenomenon. We have a Kawasaki robot RS025Ncommunicate in which we run a Main to communicating in TCP/IP with a client sending commands and executing them in a while loop. Something like the following:

    We are experiencing a very strange phenomenon. Suppose, the robot is not receiving any communication, i.e. no commands being executed with any JMOVE or LMOVE commands. The robot is in MOTOR ON and is in CYCLE START. We switch from REPEAT to TEACH. Then, we move the robot to another position. Finally, we switch back from TEACH to REPEAT, turn back on the motor, and give CYCLE START. We notice that the robot moves back to the same position it was before being moved in TEACH mode.

    Why is this happening? Despite no command being executed by the robot, why does it move back to the same position it was before being put in TEACH mode? Have you ever noticed this?

    Thank you so much in advance. I really appreciate any help you can provide.

    I would check your code, as the example you have given is not the code your running is it.
    Sounds like no handshaking is being used between comms and motion segments.

    You wouldn't normally have comms and motion segments in the main routine as one will always execute before the other and as the priority in the main routine is given to motion segments, then read ahead is probably the key factor here.

    Not that I am saying that is your issue, but seems plausible.

    What does Kawasaki say about it?

    Hey kwakisaki. Thanks for your response. I would have shared the full code but our company policies do not allow it.

    We are actually using the main to only execute the motion commands in a while loop, and these commands are taken from a command queue. The queue is filled by the TCP/IP communication program, which runs on a parallel PC Program. We have implemented semaphores to protect the queue. We had extensively tested these.

    I'm very sure that no motion commands are being run when we put the robot in TEACH mode. It is true that we do not stop the CYCLE nor turn OFF the MOTORS before switching to TEACH mode. But it sounds very strange to me that when back to REPEAT (and MOTOR ON and CYCLE START) the robot has to move to the state in which it was before being put in TEACH.

    Kawasaki support will come tomorrow but we fear they might not give us a good idea of why this is happening.

    I respect you cannot share the code, but in the same sense, I cannot just go off an explanation of the mechanism as that does not reflect code.

    You say your TCP/IP runs parallel......No it does not, there is a processing speed difference Main tasks and PC Tasks (Ask Kawasaki about this).

    Quote from dhindhimathai

    Kawasaki support will come tomorrow but we fear they might not give us a good idea of why this is happening.

    Would be interested to hear what they say as the other thing, this could be firmware related which would require some further investigation probably.
    Have some faith.............:top:

    I did something a while back using Arduino RF and a 3D printed simple jogging box which I implemented with KRoset using TCP/IP which worked quite well, but never got the opportunity to interface on a live robot so I am sure what you are trying to achieve is doable:

    KRoset (Licensed Version) -3D Printer, Arduino and KRoset funtime. (youtube.com)

    Quote from dhindhimathai

    We are experiencing a very strange phenomenon. Suppose, the robot is not receiving any communication, i.e. no commands being executed with any JMOVE or LMOVE commands. The robot is in MOTOR ON and is in CYCLE START. We switch from REPEAT to TEACH. Then, we move the robot to another position. Finally, we switch back from TEACH to REPEAT, turn back on the motor, and give CYCLE START. We notice that the robot moves back to the same position it was before being moved in TEACH mode.

    I always thought this is normal for Kawasaki robots to do a Joint move back to where it was when it was interrupted. Even if it's not why would you let your robot continue in automatic if it was moved in teach, since you don't know where or why they moved the robot and what path it will take to your next executed motion.

    Depending on your application, I find it's good practice in my opinion to be able to monitor when the robot is switched to teach mode and run an initialization routine to deal with people moving robots mid cycle.

    I usually use an autostart to monitor for teach and teach lock, then prime PG0 where the robot runs initialization code before running a routine to return safely from almost any position to a known location and then continuing normal operation in repeat.

    If it's not practical to recover automatically with a routine then you could add a SOP(standard operating procedure) to make them drive the robot close to a location before going back into repeat.

Advertising from our partners