Cubic-S, Thoughts/Opinions/Best Practices

    We recently had Kawasaki in on Saturday for mechanical repairs on a RD080N-A001. We had a significant crash back in October, and Kawasaki found damaged dowels and broken bolts in the wrist space/fulcrum tube. Generally speaking the crashes that have occurred are self induced while improperly jogging/homing. Talking with the techs they recommended we look into Cubic-S as a potential mean for mitigating crashes. this robot operates in a very small area, with a tight working envelope. I'm curious on what's everyone's experience has been with integrating, and then working with Cubic-S, from what I understand its like a stand alone software version of Fanuc's DCS, which I have a little experience with. I downloaded brochure and manual from Kawasaki. Any thoughts/opinions/ or best practice tips anyone would like to share?

    Hello,


    Can you please describe a little bit more about the crash? What happenes if the operator is doing the homing?

    The robot is palletizing?


    In order to avoid crashes, there is a collision detection function and you can tune values for each axis. There are other software methods

    or you can design a collision detection with inductive sensors in the gripper.


    I wouldn't use the Cubic-S for collision detection, i am using some software methos in order to avoid collision and improperly operation.

    Obviously I would consider more training in relation to how the robot moves to assist in preventing further crashes as opposed to just fitting 'a pseudo airbag' to stop crashes.


    ie understand interpolation modes, verify teach speed, verify interpolation modes and then press the buttons.


    More often than not, 'we' tend to be in a hurry to move the robot and overlook basic principles.

    Do you pull off in a car with the accelerator fully depressed and the steering pointing in an unknown direction with your eyes closed?

    I hope the answer is no, but my experience on the road today was definitely in that category.....but that's another story...….:censored:


    Saying that, 'we' are always going to 'press the wrong button' at some point, and some measures can be introduced:

    Cubic S

    Soft Absorber

    Collision Detection


    Personally, I would arrange for a Kawasaki Sales Tech to come in and provide some specific details on the above and also ask for their opinion in relation to your application as Cubic S could be a more expensive OTT option to use in reflection.


    Soft Absorber and Collision Detection are Software options and need to see an opposing force to function.


    Cubic S requires a hardware peripheral installed, wired and programmed for functionality including a software option to be enabled and is a more of a 'go', 'no go'


    Cubic S comes with an override button, to be used to recover from a Cubic S triggered event with reference to unauthorised zones.

    Very straight forward to install, and wire up.


    KROSET (as far as I know) does not have any option to use Cubic S or integrate with it.

    Main Configuration is done only using CS Configurator, which can be use at the same time as KROSET.

    This application is usually supplied with the Cubic S unit.


    In comparison to Fanuc DCS, Fanuc has this beat hands down, as it can all be configured and tested with Roboguide.

    Are you listening Kawasaki, please, please consider combining it with KROSET.....:justice:


    Cubic S Module is wired in series to the External E/Stop circuit on X7 of the 1TR board, therefore 'breaks' the Emergency Stop Circuit upon a Cubic S error level event.

    It can be configured for alternative stop categories, allowing for 'soft safety stops' as opposed to immediate.


    The unit itself uses the robot model and encoder values to determine where the robot/elements/links and tool points are in relation to the configured working environment and configured zones.


    It contains as standard 8 dual channel inputs and outputs which can be allocated for various functions.

    In addition, there are dedicated inputs for Tool Changing, so electrically, you can send back BCD values from a connected Tool to select/check correct tool is fitted.

    Also, there is the Networking function to interface with Ethernet/IP Safety peripherals, expanding the amount of IO with maybe located in an external PLC.


    There's obviously lots more functionality under the cover and collision prevention is but a small portion of what it has to offer and just to prevent collisions maybe a little expensive for purpose.

    Attached is an old brochure I had for Europe.

    I should have been more clear, my mistake. I was interested in using cubic-s as a means of collision prevention, not detection. Ive seen this work well with Fanuc DCS and stationary equipment. The issue arises when a "trained" employee (im using this term facetiously)" is manually homing the robot after a misload. The "trained employee" is jogging the robot via the teach pendant to a position the employee is assuming safe then either personally loading in the Homing program and then running the robot in auto or will just return the cell to the auto state and hit a "HOME" butting that triggers a call for the homing program. The issue being is that the position they jog it to is not a safe position, and the robot takes the quickest path home resulting in a crash. After talking with my OEM I'm looking at programming options i.e. slowing the speed down to a crawl in the homing program till it reaches a known approach point then resuming normal operating speed and also possibly creating work spaces and using the outputs as a mean of either controlling the path the robot takes to the approach to home or just preventing the home program from running unless it is fairly close to the approach position. Thank you for the feed back.

    Thank you for the detailed reply, this was the kind of info I was hoping for! I like the analogy of a pseudo air bag. I agree at the core this is a training/personnel issue but unfortunately I'm not in a position to mitigate those issues, I'm just directed to try and engineer preventative measures. What can you tell me about Soft Absorber and the Collision Detection software? Isn't Collision detection standard? Currently when a collision occurs the fault that appears as a over current on one or more of the joint motors. The Kawasaki techs I was working with over the weekend actually recommended Cubic-S as a means to mitigate a reoccurrence of a few of the issues we have seen. They also said they would be able to support the integration. As of right now Cubic-S looks like my last resort. After speaking with with my OEM I'm looking at programming options i.e. slowing the speed down to a crawl in the homing program till it reaches a known approach point then resuming normal operating speed and also possibly creating work spaces and using the outputs as a mean of either controlling the path the robot takes to the approach to home or just preventing the home program from running unless it is fairly close to the approach position. Ive never used Roboguide for Fanuc DCS modifications or implementation. Ive always done it the slow way of teaching the shape on the pendant. It would sure be nice if they worked more features into K-Roset! As always your responses are very helpful, thank you kwakisaki!

    Soft Absorber and Collision detection are just software enabled options.

    Kawasaki sometimes charge to enable these, but it depends on your relationship with them.

    Any errors related to these options include references to the option.

    Overcurrent/Overload messages are standard messages and if you are experiencing those, these are the 'max' conditions of the controller and not optional conditions - and the wrist assembly is always the 'weakest point'.


    Soft absorber 'allows' an opposing force to impose on the motors (reduce torque) in set directions.

    - If you are picking a gear and placing to mesh them together which are machined, the robot could damage the part/error out.

    - With soft absorber function, torque is reduced to the motors in relation to the expected force applied allowing for 'soft, relaxing' placement.

    - Also can be used when the robot is stationary (but executing) and you are forcing a part into the robot.


    Collision detection is the opposite in that it prevents an opposing force exceeding configured values and prevents further damage.

    It consists of either/both collision detection and shock detection and can be used in Teach or/and Repeat Modes.

    However, the robot does have to see this opposing force in order to trigger the error/stoppage which ultimately means 'contact' with an object.

    Speed is a major factor when it comes to collision detection and stopping times, therefore the slower the robot speed, the less impact damage is likely to be the result and increased sensitivity can be achieved.

    (This is why I assume Alexandru has mentioned it).

    There is also an auto recover from collision detection too, but this is based on the direction it travelled to and at the speed, and it recovers a distance relative to this and can be a little unpredictable, but can be made to work well in specific instances.


    Attached are both Soft Absorber and Collision Detection manuals for your consideration.

    As you can appreciate, already stated, collision detection does not prevent collisions.....it is there to police instances of collisions and prevent further damage.


    It depends really on the 'safety aspect', are you looking at 'Human vs Robot' or 'Robot vs Peripheral'.

    - From a standard programming perspective that is never considered safe as it can be circumvented.

    - Soft Absorber and Collision Detection are really to 'allow' or not 'allow' configured forces.

    - Cubic S is designed to be that 'fail safe' as it interrupts the External Emergency Stop circuit, removing motor power and stopping the robot and cannot be circumvented by programming by virtualising the 'physicality' of the robot and TCP volume in relation to a zone shrouding 'physical' objects.


    From what you've explained though (without going into risk assessments), you could achieve what you require without ANY of the additional options programmatically IF 'safety' is not the underlying reason and 'prevention' is just in case the experienced operator makes a mistake (we all do it) by using some of the existing features in a standard controller.


    I would certainly look into the following functions of the standard controller before committing to anything:

    - Working XYZ limit (This is a total zone that TCP motion from inside to out results in immediate stoppage) only 1 zone can be configured.

    - If this zone can be created to include your application but protect your peripherals (with an 'air gap'), this could be investigated.

    - Tool Shape points - points created around the TCP which are monitored to not exceed teach speed maximum during teach mode jogging.

    - Workspaces (which are only based/monitor current TCP position within a cube) which can turn on/off dedicated outputs.

    - Using these, you can create specific recovery routines to the workspace and call them in based on the status of the workspace signals.

    - Look at SLOW REPEAT (system switch and dedicated signal) to enable and force a preset percentage speed until not required.

    - Collision detection could be introduced as well as the above, to give another level of protection if any of the above were circumvented.


    All of the above could be implemented in KROSET and tested for functionality, so I would certainly explore the programmatical route and see if these could fit your circumstances if 'prevention' is the priority and not 'safety'.

    Plus, it would give you more 'tools' to your Kawasaki tool box and understanding of standard controller capabilities.

    Hello,


    Defining a home position in the robot, it will allow you to have a tolerance for homing posiiton and a dedicated signal output.


    Having that dedicated, you can do a program in order to check if the robot it is in home position or not.

    I have done home recovering in two ways:


    1. Semi-auto version. If the robot needs to restart from the beginning, the operator had to keep pushing one button in order the robot to recover back to home position, releasing the button and the robot not in home position, the robot stops. When the robot reach the home position from the stack programs, it loads automatically the beginning program. The robot speed was done with ABS_SPEED allowing you to run with a certain speed, set in mm/s. The robot was still in repeat mode, the operator needs only to keep pushing one button until the robot reach the home position. This method is usefull if the robot cell allows the robot to recover from any position (indicated only from the program locations) and the operator will not care about the JOINT, BASE or TOOL motions.


    2. Manual version. The operator drive manually the robot in Home position and when the robot will reach the home position is automatically load the beginning program. One great feature is not to allow the robot to continue in repeat if the robot has been moved manually and it is in a different position than

    home position or the last position in repeat mode. This way you will avoid crushing.

    "Soft Absorber and Collision detection are just software enabled options.

    Kawasaki sometimes charge to enable these, but it depends on your relationship with them.

    Any errors related to these options include references to the option.

    Overcurrent/Overload messages are standard messages and if you are experiencing those, these are the 'max' conditions of the controller and not optional conditions - and the wrist assembly is always the 'weakest point'.


    Soft absorber 'allows' an opposing force to impose on the motors (reduce torque) in set directions.

    - If you are picking a gear and placing to mesh them together which are machined, the robot could damage the part/error out.

    - With soft absorber function, torque is reduced to the motors in relation to the expected force applied allowing for 'soft, relaxing' placement.

    - Also can be used when the robot is stationary (but executing) and you are forcing a part into the robot.


    Collision detection is the opposite in that it prevents an opposing force exceeding configured values and prevents further damage.

    It consists of either/both collision detection and shock detection and can be used in Teach or/and Repeat Modes.

    However, the robot does have to see this opposing force in order to trigger the error/stoppage which ultimately means 'contact' with an object.

    Speed is a major factor when it comes to collision detection and stopping times, therefore the slower the robot speed, the less impact damage is likely to be the result and increased sensitivity can be achieved.

    (This is why I assume Alexandru has mentioned it).

    There is also an auto recover from collision detection too, but this is based on the direction it travelled to and at the speed, and it recovers a distance relative to this and can be a little unpredictable, but can be made to work well in specific instances.


    Attached are both Soft Absorber and Collision Detection manuals for your consideration.

    As you can appreciate, already stated, collision detection does not prevent collisions.....it is there to police instances of collisions and prevent further damage."


    All very valuable information, I'll review the manuals and look into whether these software add ons would be worth while to add to my companies equipment. I'm particular interested in the Soft absorber because our robots do a lot of placing into tight quarters.


    "It depends really on the 'safety aspect', are you looking at 'Human vs Robot' or 'Robot vs Peripheral'.

    - From a standard programming perspective that is never considered safe as it can be circumvented.

    - Soft Absorber and Collision Detection are really to 'allow' or not 'allow' configured forces.

    - Cubic S is designed to be that 'fail safe' as it interrupts the External Emergency Stop circuit, removing motor power and stopping the robot and cannot be circumvented by programming by virtualising the 'physicality' of the robot and TCP volume in relation to a zone shrouding 'physical' objects.

    From what you've explained though (without going into risk assessments), you could achieve what you require without ANY of the additional options programmatically IF 'safety' is not the underlying reason and 'prevention' is just in case the experienced operator makes a mistake (we all do it) by using some of the existing features in a standard controller.

    It depends really on the 'safety aspect', are you looking at 'Human vs Robot' or 'Robot vs Peripheral'."


    This would be used to protect peripheral equipment/the robot itself. The robot is encased in a enclosure and locked by a safety interlock.


    "I would certainly look into the following functions of the standard controller before committing to anything:

    - Working XYZ limit (This is a total zone that TCP motion from inside to out results in immediate stoppage) only 1 zone can be configured.

    - If this zone can be created to include your application but protect your peripherals (with an 'air gap'), this could be investigated.

    - Tool Shape points - points created around the TCP which are monitored to not exceed teach speed maximum during teach mode jogging.

    - Workspaces (which are only based/monitor current TCP position within a cube) which can turn on/off dedicated outputs.

    - Using these, you can create specific recovery routines to the workspace and call them in based on the status of the workspace signals.

    - Look at SLOW REPEAT (system switch and dedicated signal) to enable and force a preset percentage speed until not required.

    - Collision detection could be introduced as well as the above, to give another level of protection if any of the above were circumvented."


    I've attached my program modifications I made earlier. I've slowed down the robot travel speed so hopefully if the robot is homed from a less than ideal position then the operator will be able to stop it before it crashes and if it does hit something the slower rate will lower the likelihood of damage. I am also considering adding in Work Spaces. Depending on which Work Space output is on the robot will take a more precise path to home then.

    Now that's an interesting method of programing. Is there any way you could show me n example or two?

    Instead of SPEED 200 MM/S you can use ABS_SPEED. For example:


    ABS.SPEED ON

    SPEED 200 MM/S

    ACCURACY 30

    JMOVE tx1

    ABS.SPEED OFF


    Did you set any HOME position in the robot?


    In order to activate the ABS SPEED you have to activate the switch: Aux-->Advanced Setting-->System switch--->(page 3 ABS.SPEED).


    To have a HOME position in the robot go to Aux-->Basic Setting --> Home position. You can set 2 HOME positions.


    Those home recoverings are done specific for each system and the code is hard to understand.

    I’ll have to delve deeper in my manuals tomorrow at work as I am unfamiliar with the exact function of that command. And as for the “home” position thats just a trans point specified by the OEM, they do not use the method in the basic settings for some reason.

    Quote

    yes, it’s a trans position that was specified by the OEM.

    Kawasaki has recommended this then?...…...I'm astounded if this is the case..…………:gaah:

    I would never use or recommend anyone to use this method for many reasons including:

    - Transformation locations have more than 1 kinematic solutions available.

    - Could result in a dangerous motion path to it, if a pre determined posture based on the target transformation posture (not location) is not used.

    - It could also result in external harness tearing unless a suitable dressing is applied.

    - This position is open to POS MOD button and re-teaching on purpose or by accident by operator.

    - When operators/programmers talk about HOME location, this could result in 2 different conversations.

    - Visiting Service Techs may assume standard Kawasaki HOME is in use which may result in collisions.

    - Using one of the dedicated home postures available, means you use the HOME/HOME2 command only.

    - HOME/HOME2 command includes a JMOVE already to it.

    - HOME/HOME2 posture has dedicated optional accuracy and signal that only needs setting, not programmed.

    - HOME/HOME2 command in a program is not available to POS MOD button for re-teaching on purpose or by accident.

    - HOME/HOME2 posture is a precision point, no ambiguity in joint posture for location.


    As I mentioned, I would never use or recommend this method, but I am not saying it is wrong to do so as it can be made to work......but if you are receiving pre-made cells, using this standard, you have a 'grey area' when it comes to recovering to that position either by visual or automated recovery unless carefully programmed.


    Just my 2 cents...…..Stay safe...…:top:


    p.s I have just expressed my opinion, please do not misconstrue my comments that I am in anyway trying to undermine your supplier, as it is possible there are very good reasons for using this method in relation to your application and cell environments...………..:respect:

    By OEM I meant the company that designed the whole cell and integrated the robot. I too thought it was troubling why the integrator would set the equipment up this way. In fact judging by the first part of your comment, this may be contributing to my operator mishaps when homing. Your feed back is always very appreciated kwakisaki, I’m still familiarizing myself with Kawasaki robotics so I’m see a lot for the first time. I’m am attending my first AS Language class next week though so that will help!

    Quote

    In fact judging by the first part of your comment, this may be contributing to my operator mishaps when homing.

    Totally agree, could offer some levels of confusion...…….:top:


    Yes, indeed, I am in a similar situation with Fanuc and personally I like to be able to grasp/be exposed to standard features and practices of what the Controller can offer before pursuing applied programming techniques that more experienced users/programmers/integrators use as regular templates for their systems.

    This way, I can then appreciate/understand why they adopt these alternative methods, therefore adds to the 'toolbox of knowledge' for the product.


    As always, there are many ways to integrate a system and if you can keep things simple by using the built in features, then operators and future maintenance, troubleshooting also becomes simpler.

    However, with applications coming more complexed, more often than not, these applied programming techniques sometimes become a necessity.


    That also means a possibility of 'information overload' when you are starting out and some basic instructional courses will usually cover/include standard features and fundamentals as opposed to complex techniques and also gives you the opportunity to get some feedback from the instructor/other attendees if it's a generic course regarding your application too.


    You will enjoy and get a lot out of the AS Language course, and come away with some additional information that should fill some gaps of standard controller capabilities you were not aware before, therefore putting you in an ideal position of understanding these applied programming techniques your integrators will be using.

    I programed in the speed reduction for the homing program and the operators seemed pretty happy with that for now. I'm still planning to add in work spaces which then I'll use those defined outputs to choose pre program paths. I was at AS Training last week so I hadn't the time to return to this problem. This morning I was working on another issue. My plan is to try and set this stuff up in K-Roset then reincorporate it the live cell. Thanks again for your feed back earlier and following up.

    What the robot is doing? Can you send any picture with the cell?


    Yes, doing in k roset it is a good plan. I also did the home recovery in k roset and it was pretty difficult to find all zones which the robot might be.

    Quote from Alexandru

    What the robot is doing? Can you send any picture with the cell?


    Yes, doing in k roset it is a good plan. I also did the home recovery in k roset and it was pretty difficult to find all zones which the robot might be.

    I actually have a video of it motion but Im having a hard time posting it. Even in a compressed file it crashes my browser and reloads the page when I try to attach it to my post.

Advertising from our partners