Robot slows down even though speed in program is constant

    So Im in the early stage of 3d printing with our MPL 800 DX100 but for some reason the robot slows down for a while before getting up to speed again.


    The speed in the program does not change at all.


    In the video you see that when it comes to a corner it slows down and when its out of the corner it speeds back up again. This did not happen in the begining of the print. It started when it came to a certain height.


    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    Does anybody knows what could cause the robot to slow down like this?


    UDS11.txt

    If your velocities for the moves are the same, it could be possible that you are close to singularity. I have had this happen to me before in a different application. I had to change my orientation slightly to avoid it.

    I see your program. Looks like it was computer generated. I bet you have hundreds of points that you don't need.


    Another thing. Why do you turn the extruder on every point ? That's so much processing time wasted.


    Anyway, that didn't answer your question (or may be did). I just wanted to point out some issues




    CALL JOB:EXTRUDERON

    MOVL C03098 V=22.8

    CALL JOB:EXTRUDERON

    MOVL C03099 V=22.8

    CALL JOB:EXTRUDERON

    MOVL C03100 V=22.8

    CALL JOB:EXTRUDERON

    MOVL C03101 V=22.8

    CALL JOB:EXTRUDERON

    MOVL C03102 V=22.8

    Retired but still helping

    Quote from swr98

    If your velocities for the moves are the same, it could be possible that you are close to singularity. I have had this happen to me before in a different application. I had to change my orientation slightly to avoid it.

    That could case the robot to slow down but with this program i'm no way near a singularity .

    You are right. It is computer generated but I dont know how to determine which points I dont need. There is not good reason why the extruder turns on at every point. The reason is the way the software generates the JBI file. We cant avoid it wihtout doing some alternations to the post processor which is a phyton script. Currently we have no one in the company with the skills to change it. It will be taken care of eventually.


    I tried manually to remove all the extruderon/off commands but that did not make a difference.


    I tried to cut a slice of the hole print where i knew it slowed down. If I moved this slice to be printed directly on the table there was no slow down in the speed. If i moved the slice to be printed 35cm (14 inch) higher up it slowed down as usual.

    Quote from jba

    I tried manually to remove all the extruderon/off commands but that did not make a difference.

    You can use notepad++ (it's free) and then the command CTRL+H to eliminate instantly all the EXTRUDERON/OFF lines. Maybe it will no make difference but for the programming reason is highly recommended.


    For the slowing down:

    as swr98 said the reason is probably singularity or an high number of points

    Edited 2 times, last by Motouser ().

    Quote from hermann

    You should post a video that shows the axis 4/5/6 during the slow down. I bet, we will see a singularity.

    As requested:

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    At around 0:04 it slows down and at 0:09 it speeds back up

    I'm out.

    Looks like a palletizer robot.

    He has no singularity.


    Edit: may be he has, don't know this robot, but the view is not good, because the axis 4/5/6 are not really shown.

    View from the side will be much more expressive.

    Hello,



    Quote from jba

    The speed in the program does not change at all.

    I think this is a myth. However your program does use V=22.8 majority of time but there are many occasion it has V=180.00. By seeing your gigantic program it looks like it has a pattern changing its speed from 22.8 to 180.00. I am putting some portions of your program.


    CALL JOB:EXTRUDERON

    MOVL C03890 V=22.8

    MOVL C03891 V=180.0

    MOVL C03892 V=180.0

    CALL JOB:EXTRUDERON

    CALL JOB:EXTRUDEROFF

    MOVL C03893 V=180.0



    CALL JOB:EXTRUDERON

    MOVL C03787 V=22.8

    MOVL C03788 V=180.0

    CALL JOB:EXTRUDERON

    CALL JOB:EXTRUDEROFF

    MOVL C03789 V=180.0

    CALL JOB:EXTRUDERON

    CALL JOB:EXTRUDERON



    CALL JOB:EXTRUDERON

    MOVL C03787 V=22.8

    MOVL C03788 V=180.0

    CALL JOB:EXTRUDERON

    CALL JOB:EXTRUDEROFF

    MOVL C03789 V=180.0




    CALL JOB:EXTRUDERON

    MOVL C00048 V=22.8

    MOVL C00049 V=180.0

    MOVL C00050 V=180.0

    CALL JOB:EXTRUDERON

    CALL JOB:EXTRUDEROFF

    MOVL C00051 V=180.0

    CALL JOB:EXTRUDERON

    CALL JOB:EXTRUDERON




    There are many more occasion where it changes speed in program. In order to troubleshoot this problem if you can create same program using in which it can give you all points in Robot coordinates instead pulse. This will make it much easier.


    I have never used RobotDk but may be reason for this many points in your program is because of your precision level.Higher the precision will produce more and accurate points I believe if you can not change it though software you may be able to change it in post processor python script.

    Regardless how many point the program have it does not change the fact that it runs with a constant speed at the begining of the print but as it moves further away from the table it slows down as shown in the video.


    I have tried to make a very simple program directly on the robot. 4 position variables that forms a 500x500mm square. When the z value is set to table height the program runs without any issues.


    Setting the z value to 650mm above table height the robot slows down but only when it going "in and out". When it goes from "side to side" it moves at the set speed.

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    Quote from WattUp

    Is your tool weight & center of gravity set up?

    The tool weight is set but the software doesn't have the ability to calculate center of gravity (the w.grav.pos measure is not available) I tried to put in some random values but the robot behaived the same.

    Once again: If You make a new video, You should show more parts of the robot: last segment of the upper arm with extruder, from the side.

    Don't know how Yaskawa calculates the transformation. If they use one model for all robots and for this special robot they block the Axis 4 and 5, may be there is a internal singularity.

    May be You can change the behaviour if You change the orientation of last axis.

    Quote from hermann

    Once again: If You make a new video, You should show more parts of the robot: last segment of the upper arm with extruder, from the side.

    Don't know how Yaskawa calculates the transformation. If they use one model for all robots and for this special robot they block the Axis 4 and 5, may be there is a internal singularity.

    May be You can change the behaviour if You change the orientation of last axis.

    Here is a video from the side. It is the same square as in #12


    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    A small update. We had a guy from motoman to have a look at it. He did not have a solution but confirmed that for some reason the L axis did not move at the corret speed. He tried to simulate it in a program(motosim maybe) and it did the same. If he tried wit a MPL 500 robot there was no issues what so ever. So something is different in the MPL 800 robot. He will investigate further and get back hopefully with a solution.

Advertising from our partners