Changing the robot speed on the fly, mid-movement

    Hello everyone,
    I'm a longtime lurker and, as of today, first time poster.

    I started working with Kawasaki robots 2 years ago and this board has been a trove of lifesaving information a lot of times, so first of all THANK YOU! :respect:

    Secondly, my problem: I've been asked to implement a solution to change the speed of the robot ( an RS007n with F controller) mid-movement without stopping; from my experience I don't think it is possible, but I thought it was worth asking here.

    My current solution looks like this, I tested it on the simulator and it seems to be working:

    .PROGRAM autostart.pc() #0
    10 TWAIT 0.2
    IF SIG(1) THEN ;signal to trigger the hold and speed change
    CASE TASK(1) OF ;returns the status of the main program (values considered: 1 running, 2 held)
    VALUE 1: ;if the program is running, it holds the robot and changes the speed
    MC HOLD
    MC SPEED 6
    VALUE 2: ;if the program is held, the program resumes and the signal get reset
    IF (TASK(1)==2) THEN
    MC CONTINUE
    SIGNAL -1
    END
    TWAIT 0.2
    END
    END
    GOTO 10
    .END

    Obviously in a real robot implementation I will get the request to change the speed and the speed value from the PLC, so the program will be a bit different.

    Any suggestions are welcome.

    Quote from Motouser


    I don't know if you can or know but you can simply change the REP. SPD in the TP?

    Just click on it and apper a submenu where you can increase or decrease speed by step of 10% of the max and you can do it on the fly.

    Using the the command MC SPEED *number* in a PC program is the same as using the command SPEED in the console or changing the speed on the teach pendant like you suggested (or at least it looks like it, as the change of speed is instantly reflected on the teach pendant)

    The problem is that the new speed is not applied untile the robot has completed his current movement: if the robot is moving back and forth between point A and point B, and it receives a new speed while going from A to B, that speed won't be applied until it starts moving from B to A.

    The program that I wrote in my opening post "solves" this by stopping the robot with the command HOLD, applying the new speed and resuming the movement (thus creating a new movement to which the speed is applied).

    I wanted to know if there's a way to do it on the fly, without stopping the robot and without waiting for it to complete is current movement.

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

    I think you may need to contact Kawasaki direct regarding this.
    I know with Kawasaki Arc Weld spec robots, you can override the main speed parameter of the weld instruction by using the Teach Pendant.
    - This dynamically increases/decreases the tip speed (during the motion).
    - But this has to be done manually via the Teach Pendant and is only available in Arc Weld Spec.
    - But this is also means there is something that exists in software in order to accomplish this.

    Therefore, in theory, it is implemented of sorts, that's why I am confident Kawasaki will be able to provide a more accurate answer.

    It may be there is an additional option required installing and possibly changing the spec of your robot to Arc Welding (even if it is not arc welding) in order to have this feature, but looking at the manuals, it doesn't seem to be available as a 'standard' function.

    Would be interested to hear of any feedback after you've contacted them though..... :top:

    Quote from e-ray


    I think that, if you want to use this for some SAFETY reason you must have Cubic-S unit and use Protective stop function

    Yes, I will be using a Cubic-S and the Protective Stop function, but as the name implies that will still stop the robot.

    The system (not my project or idea) will have 3 layer of laser barriers, the idea was that the first layer would trigger a slower velocity, the second layer would trigger the Protective Stop and the third would trigger the emergency stop; if the speed cannot be reduce mid-movement without stopping, the first layer is largely redundant.

    And that's why I'm asking if it is possible :icon_smile:

    Quote from kwakisaki


    So how are going to get Cubic-S to send a new AS Command?
    - This bit I am really interested in.... :top:

    I have no idea and I don't think it is possible, it will be my first time working with a cubic-s :icon_confused:, that's why I was asking. All the informations that I have about it came from the manuals for now.

    Maybe I've not explained it well (sorry, english is not my first language :icon_frown:), but I've not been involved in the planning of this project; I've been only asked to work on it after everything was already decided.

    The first barrier would not be used to give a safe signal (slow down only), only the second (protective stop category2) and the third (emergency stop) would. I cannot give you more information on the project for confidentiality reasons, but to the people that planned the project, it made sense.

    Edit: Sorry kwakisaki, I totally did not see your first reply to my post, I must be blind :icon_neutral:. I will try to ask our supplier what you suggested, hopefully I will get some useful information to share!

    Edited once, last by buontempone (July 26, 2019 at 12:46 PM).

    I am very interested in this topic on how it progresses and willing to through in what I currently know to see if you can achieve your target and totally understand where company IP and confidentiality is concerned...….. :respect:

    Yes, what I was talking about with the 'speed' changing dynamically, was based on what you originally said.
    When a motion is in progress, it is in execution but the speed has already been processed/applied before commencing execution.
    Therefore a speed change request will not be processed again, until the next process 'tick' of the CPU or a break in the execution such as Hold as you've pointed out.
    If you do ask the question at Kawasaki, this would be a great option to have and from what I have seen on the Arc Weld Spec, is currently in place, and just needs to come out as a specific option and AS Command applicable.

    I was not aware of the Cubic-S option before replying, which makes what I said sort of irrelevant, but is still worth an email perhaps.

    Quote

    Maybe I've not explained it well (sorry, english is not my first language ), but I've not been involved in the planning of this project; I've been only asked to work on it after everything was already decided.

    Not at all...…Often people that plan/make decisions may be based on what they have seen in a demonstration as opposed to being exposed to the 'actual' configuration details involved.
    (Not to say this is always the case).

    I have seen other 'safety devices' DCS etc in other robots (but never used them) and all demonstrations I have seen, always show, speed changes based on something similar to what you describe as your 'layers'.
    However, I do not quite know just how they achieve this (as I have never used them).

    Considering your similarities to this and in conjunction with what I know about Cubic-S (I may be missing something).
    - Cubic-S monitors encoder values of the specific robot parameters in conjunction with configuration to 'allow/deny' motion.
    - It works in parallel to the Controller and cannot send any commands to the Controller, so direct speed commands cannot be transferred.
    - Cubic-S only makes/breaks the 'External EStop' circuit based on the 'allow/deny' configuration set using CS Configurator.

    So, unless I have missed something, then the only way of 'talking' to the Controller is by way of the safety IO of Cubic-S or/and the IO of the safety peripheral in use such as a light curtain to connect to the standard IO of the Controller.
    Then by using a background task, or even main motion routine, react to either:
    - Safety IO of Cubic-S (which I don't think is possible directly for the Controller to monitor for - This I am not sure about).
    - Use the dual channel outputs of Cubic-S and directly drive standard IO logic of the Controller and monitor for these states.
    - Use the safety peripheral output directly to drive the standard IO logic of the Controller and monitor for these states.

    If the above is the only way, then it's a case of configuring Cubic-S/Safety peripheral to send the specific Output at the time you want to initiate a 'speed change' in the Controller.

    In my simplistic mindset, this would mean possibly individual or a combination of a location taught prior to/at the light curtain trigger:
    - The location joint angles to be stored in Cubic-S to send an output when the joint angle/joint angle range is achieved.
    - The speed monitoring option to be enabled by the light curtain to stop the robot if it doesn't slow down (Cubic-S Protection).
    - A background task to monitor for this input from the Joint angle output/Speed Monitoring output and initiate the MC Speed change.
    - This should be instantaneous be applied for the next program step (resulting in a slow speed).
    - The Joint angle will be different, output from the joint angle is off, the background task will not initiate any further speed changes.
    - The speed monitoring function will kick in and stop the robot should your background task fail/or other reasons.
    - When it hits the 'next layer' your overall protection comes in.

    I think there will be mileage to explore some of the above, but I think fundamentally the only way of achieving this is by use of the IO of the Controller to be integrated into to the system.
    Of course, there may be areas I am missing out on (there may be additional functions/options available in Cubic-S now) and if there are other solutions, I would sincerely love to hear about them for sure.

    Hope this helps...……….

    Quote from kwakisaki


    So, unless I have missed something, then the only way of 'talking' to the Controller is by way of the safety IO of Cubic-S or/and the IO of the safety peripheral in use such as a light curtain to connect to the standard IO of the Controller.
    Then by using a background task, or even main motion routine, react to either:
    - Safety IO of Cubic-S (which I don't think is possible directly for the Controller to monitor for - This I am not sure about).
    - Use the dual channel outputs of Cubic-S and directly drive standard IO logic of the Controller and monitor for these states.
    - Use the safety peripheral output directly to drive the standard IO logic of the Controller and monitor for these states.

    If the above is the only way, then it's a case of configuring Cubic-S/Safety peripheral to send the specific Output at the time you want to initiate a 'speed change' in the Controller.

    Is it not possible to use the Cubic-S in conjunction with Profinet (using the adapter) and a PLC? That's how the customer planned this, and from what I know they consulted with their Kawasaki supplier before deciding to go ahead.

    If it is a you say, it's going to be a problem for sure; I'll add this to questions for the supplier and keep you posted.

    Well, this is what I was referring to when I said:

    Quote

    (there may be additional functions/options available in Cubic-S now)


    And indeed there is...…………..

    Not too sure about profinet, as isn't this just a standard fieldbus, not safety network?

    However, there is a network function with Cubic-S (using Ethernet/IP) reading the manuals where the Controller interfaces with an external PLC and it looks like it does indeed communicate with the Cubic-S Module......But on the IO level only.

    Attached is the manual, if you read this in conjunction with the Cubic-S Manual I think you could be onto a winner...….just a case of configuring the port and allocation in the Controller (and that information appears to be in the manual too)

    Hope this helps...……...

    Quote from buontempone

    Secondly, my problem: I've been asked to implement a solution to change the speed of the robot ( an RS007n with F controller) mid-movement without stopping; from my experience I don't think it is possible, but I thought it was worth asking here.


    It is tricky, but it is possible.
    Try to use "slow repeat mode" - this is the only method known to me to change the speed during movement (since D-CON).

    Firstly in AUX / advanced setting / set slow repaet speed expressed in % (unfortunately it can't be in mm/s unit).
    Then use the dedicated signal "Ext. slow repeat mode".

    Of course, you should immediately activate Cubic-S speed monitoring on the two-channel input when the signal "Ext. slow repeat mode" is turned on (actually off because this one signal is in negative notation).

    Quote from kawa

    It is tricky, but it is possible.
    Try to use "slow repeat mode" - this is the only method known to me to change the speed during movement (since D-CON).

    Firstly in AUX / advanced setting / set slow repaet speed expressed in % (unfortunately it can't be in mm/s unit).
    Then use the dedicated signal "Ext. slow repeat mode".

    Of course, you should immediately activate Cubic-S speed monitoring on the two-channel input when the signal "Ext. slow repeat mode" is turned on (actually off because this one signal is in negative notation).

    I almost can't believe it, it works flawlessly ( or at least on the simulator it does)!! :cheer: Thank you, kawa!

    But I have to say, the manuals really try to hide this functionality, from the explanations it looks like it would work only when you start moving the robot again.

    kwakisaki: I'm still waiting for an answer from the supplier regarding the possibility of working with both Cubic-S and Profinet, as soon I have something I will post it.

    I have just received confirmation: both Cubic-S and ProfiNet can be used on the same controller, but obviously cannot interact with one another (ProfiNet is not safe,after all).

    So the final implementation will be probably like this:

    - First barrier: the PLC will trigger the Ext. Slow Repeat via ProfiNet, and after *ToBeDetermined* milliseconds will trigger the Cubic-S speed monitoring via ProfiSafe.

    - Second barrier: the PLC will trigger the Cubic-S Protective Stop Type 2 via ProfiSafe.

    - Third barrier: the PLC will trigger the Cubic-S Emergency Stop via ProfiSafe.

    Thank you very much, everyone! :top:

Advertising from our partners