Waiting until the robot has stopped completely

    Hello!


    I'm new to Fanuc robots, and I have a problem that I hope you can help me with. My problem is that I have several cases where I want the robot to stop completely before it continues in the program. Otherwise I will get some wrong measurements in my application. I have tried to use a FINE position, but the robot still seems to continue in the program before the robot is at a complete standstill (so measurements are performed too early). I could add a delay after the FINE position, but cycle time is always an issue, so I want to avoid that. It is also hard to determine what the correct wait time is in all cases. How would you make sure that the program pointer does not continue in the program before the robot has stopped completely?


    Thanks in advance!


    /RoboticsMan

    I think there is an appropriate command called 'break' that may assist with your 'delay'.

    Also, I recall there is an example/explanation of application in the handling manual (not sure about others).

    I have yet to do some testing with it, but it came about during the following discussion in the following thread:

    type of termination


    Hope it helps...…….:top:

    Thank you, that is very helpful :smiling_face: I see it is an option on a movement. Is it possible to have a similar effect without the movement? So that it just makes sure that any previous movements have stopped...


    Thanks in advance!


    /RoboticsMan

    Fine termination should be all that is necessary. Adding a very small delay will also stop the robot, it could be 0.1 seconds.


    How is your measurement being performed? Knowing that may help us understand your situation better.

    Quote from HawkME

    Fine termination should be all that is necessary. Adding a very small delay will also stop the robot, it could be 0.1 seconds.


    How is your measurement being performed? Knowing that may help us understand your situation better.

    Measurement is done in several different ways. Usually it is done with a camera that is mounted on the tool of the robot. I'm testing it in the simulator in RoboGuide. I'm sending some positions to the robot. The movements are FINE movements. The robot reports back that it is done with the movements, while it is still moving in RoboGuide. This is obviously wrong. I'm pretty sure the same is the case in real world (I don't have access to the robot, so I cannot test it, but I have seen some indications that this might be the case).


    /RoboticsMan

    Surely you have some sort of synchronization between:

    - Decelerating to the location then requesting the Camera to activate.

    - Waiting for the Camera to finish processing the image.

    - Accelerating away.


    Have you got any example code you could post?

    Quote from HawkME

    How does the robot report that it is done with the movement, what signal? I've never seen a Fanuc "look ahead" on a Fine movement.

    I just made it report back via a socket connection. The points it is moving to are calculated on a PC and sent to the robot. When the movements have been carried out, it reports back.


    /RoboticsMan

    I am wondering if your issue is due to when the socket communication is being triggered. What triggers the socket connection to report back? Can you use a digital output that you turn on after the movement is complete to trigger it to report back?

    Quote from HawkME

    I am wondering if your issue is due to when the socket communication is being triggered. What triggers the socket connection to report back? Can you use a digital output that you turn on after the movement is complete to trigger it to report back?

    The code for the socket connection is being executed immediately after the movement code. So if the program pointer continues too early, then the message will be sent back to the PC too early.


    I have started to wonder if maybe the graphics in the simulation are lagging behind the program execution, adding to the confusion. I will look into it.


    /RoboticsMan

    I never 100% trust simulation cycle times for that specific reason (graphics rendering, screen refresh etc).

    They are improving a lot, but when it's in real world, those times are what are important and I only ever rely on real world times.


    If you can get the structure in place in simulation and program knowing the areas that you can place a variable change in to increase/decrease cycle time, then you are in a ball park area I think.

    The main thing is the timing of the triggers.

    Surely you have a handshake in place between Robot and PC?

    I would use the 'STEP' function to assist in determining where the triggering is occurring.

    Quote from kwakisaki

    The main thing is the timing of the triggers.

    Surely you have a handshake in place between Robot and PC?

    I would use the 'STEP' function to assist in determining where the triggering is occurring.

    So it works like this:

    1) PC sends coordinates to robot

    2) Robot moves to coordinates

    3) Robot reports back to the PC via socket connection when it is in position.

    4) PC triggers camera (that is just one example, sometimes other things happen after the movement)


    The point is that the robot should not continue in its program before the robot is at a standstill. I will look into it further, to make sure that I have not confused myself.


    /RoboticsMan

Advertising from our partners