Continious Motion Type 2 with variable path length

    Hello guys


    I just recently recieved a Kawasaki RS007L with a F-controller, and I trying to write an interface on the controller, to send paths from my PC to the robot.


    I have a PC program running on the controller, receving the data points and putting them into an array, along with speed settings etc.
    I then start a robot program wit MC Execute to execute the path.
    My problem is now regaring continious motion with motion type 1 and motion type 2
    If I use a program like this:


    I get a nice continious motion as I want (motion type 2 I believe it is called), but this only works for a fixed path length.


    If a make it to use variable path length like this:


    The path is run as a continious motion, but the robot slows down between each iteration of the FOR loop. I far as I can see in the manuals, it is because the motion type is automatically set to type 1, when I use a FOR loop (because of the branch possibility)


    So my question is now, is there any way to "force" a motion type 2, so the robot does not slow down between the points, when having a variable path length?



    - Nile

    hello,,


    I am not sure about it, but I think you have to modify your pg. by adding new line CP ON after accuracy.


    such as:


    SPEED 100 ALWAYS
    ACCURACY 25 ALWAYS
    CP ON
    LMOVE #STARTPOINT
    SPEED 50 ALWAYS
    FOR I = 1 TO 5
    LMOVE A
    C1MOVE B
    C2MOVE C
    C1MOVE D
    C2MOVE A
    END

    I should probably have mentioned it, but the CP switch has already been set to ON before calling each of the programs.

    Welcome to the forum........... :beerchug:


    I've experienced this before, and never really got to the root cause of it, just worked around it.
    - I'd agree that it is attributable to the FOR/END and could also be attributed by speed and distance between motion segments and also robot posture.
    - Try using mm/s (if you're maintaining TCP orientation) or deg/s (if you're changing TCP orientation) as a speed unit when using Circular Moves instead of percentage and see if that improves any.


    I steer clear of FOR/END where I can for motion segments for this very reason.

    Thank you for the answer.


    I tried to change the SPEED setting to MM/S, unfortunately I see the same behavior, the same goes for Linear movement instead of Circular movements.


    I tried to "expand" the For loop to include 4 motions (C1->C2->C1->C2) and doing so make the velocity decrease only appear for every fourth point instead of every second point, so the problem it definitely related to the FOR/END attributes.
    I made a few other test to see if I could come around the problem, in which I discovered that it seems to be every program structure including an END statement that makes it happen (FOR, IF etc.), while commands such as PRINT is no problem.


    According to the documentation (AS Language Reference Manual section 4.5.4 to 4.5.5) the problem happens because the program cannot "see" the next motion command (the next iteration of the for loop) and thus reduces the speed when approaching the point as see in the figure attached (from the section in the manual stated above).


    It therefore seems that I have to write the program without FOR/IF statements, which I cannot really figure out a way to do, when it has to handle paths of variable lengths, or I will have to find a way to "notify" the program of the next motion command, such that the motion type 2 is selected.

    Would be worthwhile dropping your local distributor an email regarding this.
    From memory, I think the older D Controller did not suffer from this and I think they were extra motion parameters applied in the E Controller upwards (aswell as different resolution encoders).


    I remember some differences regarding 'coincidence by command' and 'coincidence by velocity' having an affect for continuous motion.
    - So I would certainly ask the question at least.

    Thanks so far.


    We have send an email to our local distributor, and is awaiting their response.


    I will give an update when I know more, hopefully with a solution.

    Just my 2 cents here, but I reckon it's to do with the motion planning.


    Thus having a loop somehow prevents the robot firmware from planning ahead properly. But if you multiple moves that is not in a loop it plans it properly and you get a continuous motion.


    Is there anyway you could calculate and plan all the moves ahead of time and execute them sequentially without a loop?

    I agree with ShAdOwDrAgOnS......


    I do like the FOR/END loop function but have come across some strange behaviours and I can only put it down to the fact you are processing motion and non motion commands (which logically must breakup the motion planning as accuracy and speeds are also inclusive)....I think to bridge that gap is to remove the non motion instructions completely.


    May be worthwhile inserting some accuracy/speed commands within the FOR/END to see if this assists with the issue or hinders it further....that may be a slight workaround.
    Could also test some BLOCK instructions in place of the AS and see if this yields any difference results.


    Will be interesting to see if Kawasaki come back with some explanation or some additional feature to overcome this......I'm sure there is.

    Hi there,
    I cautiously read the forum and kawasaki documentation as well about my concern of the day.
    I use a E02 and BX200L

    I want to try the Continous Path with Motion Type 2. But I found nowhere how I can activate the miotion type 2 and not the standard one?


    Actually I have a path of points every 6mm, and if the points are straight, the robot achieve the Speed requested. But is the point are in curve shapes, the robot slow down a lot ! which is not good as I have an extruder mounted on it and some material flow gunchanged...


    Reading the documentation, it looks like the motion type 2 first go further to the point I need to achieve and keep a steady constant speed....

    But I can't see how to activite this bloody motion type 2 on the robot...


    I know this post is old, but that was the only post related to my subject :winking_face:

    Thank you in advance for your answer !

    Please consult with Kawasaki first before making any adjustments in 21. Motion Setting.

    These are not 'end user' parameters and adjusting parameters without clear understanding of EXACTLY what they do, could produce dangerous motions.

    This is why they are not publicly available in standard documentation.


    Regarding your problem with speed adjustments, you could be chasing rainbows with this idea dependent on your application.


    If you have a flow controller set to deliver material at a set speed, then ANY speed changes of the robot TCP will have an adverse effect on the material delivered.

    - If the robot TCP is slower than material delivery speed, then to much material will be delivered.

    - If the robot TCP is faster than material delivery speed, then not enough material will be delivered.


    Robot speeds will have to be carefully managed around every motion instruction, in conjunction with accuracies to ensure smooth and uniform material delivery and fine tuning this way is not the usual way and, in many cases, the results will overshoot, or undershoot expectations.


    Therefore, it is common to feedback the robot TCP to the flow controller, so that the flowrate dynamically follows the robot TCP speed during material delivery.


    This is done by using sealing parameters, flowrate speed control and feeding back robot TCP speed using analogue or digital signals back to the flow controller.

    Again, I would advise to contact Kawasaki regarding this as there is no 'set method' that is applicable to all applications and may require specialist setup to achieve results.


    If you can achieve the required results, just by using programmed speeds and accuracies for your application then great, but application dependent, I would explore the other alternatives available.

Advertising from our partners