KRC2 SafeOp -- KL1500 vs Cartesian Workspaces

    The hits just keep on coming....


    My latest issue with retrofitting SafeOp into these KRC2s (KSS 5.5.15, SafeOp 2.1) is the Cartesian Monitoring Spaces.


    Long story short, despite the fact that these KL1500s are completely kinematically integrated, the SafeRDC is, as far as I can tell, measuring the Cartesian Space from $ERSYSROOT, not from $WORLD.


    I determined this by parking my safe tool ~500mm from the edge of the Cell Area (Monitoring Space 1), switched into World, and began jogging E1 away from the edge of the monitoring space. The TCP remained fixed in physical space, and in the Robot Cartesian Position monitor. But, at the same time, in the SafeOp Monitor, I could see the Safety Tool's sphere moving towards the edge of MS1. After ~500mm of jogging E1, the robot was halted by a space violation on MS1.


    I repeated the test using MS2 (temporarily expanding MS1 out to 100m), and got the same result.


    I have A1-A6 and E1 assigned to Reference Group 1, and they've been successfully run through Mastering Reference.


    I've gone back and re-read the entire Cartesian Space section of the SafeOperation 2.1 manual, and external axes aren't mentioned at all. Honestly, until I ran into this today, it never occurred to me that this might be an issue.


    Is this version of SafeOp simply not capable of handling a KL-mounted robot with Cartesian spaces? Or are there extra steps I need to go through to make this work?

    Quote

    Long story short, despite the fact that these KL1500s are completely kinematically integrated, the SafeRDC is, as far as I can tell, measuring the Cartesian Space from $ERSYSROOT, not from $WORLD.

    Yes. Unfortunatly this is true. The first versions of SafeRdw did not support kinematic integration of the KL. The safety devlopers back then refused to listen to more experienced people. They initially even refused to support external axes at all. Luckily you seem to have a version that supports them axisspecific. In the newest SafeOperation this was corrected and you can choose in configuration whether to kinematically integrate the KL or not.


    In general the SafeRdw in my opionion suffers from quite a few design faults. For example its main processor is a DSP without FPU and can only perform emulated floating point operations with very low performance. Why do hardware developers design without consideration of the software that later on needs to run on them is something I will never understand. Hence later on a lot of software optimizations had do be done to allow it to run at all and these optimizations had to be reoptimized with nearly every functionality added. This even got worse because the responsible people back then refused to lower safety reaction times from 2 to e.g. 12 ms as it is now in KRC4.


    So for me the era of really usable SafeOperation starts with KRC4 which btw was designed and developed by different people.

    Quote from Fubini

    Yes. Unfortunatly this is true. The first versions of SafeRdw did not support kinematic integration of the KL. The safety devlopers back then refused to listen to more experienced people. They initially even refused to support external axes at all. Luckily you seem to have a version that supports them axisspecific. In the newest SafeOperation this was corrected and you can choose in configuration whether to kinematically integrate the KL or not.


    In general the SafeRdw in my opionion suffers from quite a few design faults. For example its main processor is a DSP without FPU and can only perform emulated floating point operations with very low performance. Why do hardware developers design without consideration of the software that later on needs to run on them is something I will never understand. Hence later on a lot of software optimizations had do be done to allow it to run at all and these optimizations had to be reoptimized with nearly every functionality added. This even got worse because the responsible people back then refused to lower safety reaction times from 2 to e.g. 12 ms as it is now in KRC4.


    So for me the era of really usable SafeOperation starts with KRC4 which btw was designed and developed by different people.

    I wonder if the same people also did the hardware design of SmartPad and SmartPad 2 for KRC4. I don't know what kind of hardware chips they use inside but for me when the SmartPad has difficulties with refreshing the screen while you browse your long program and release the slider and it just keeps on going and going on and on on it's own(SmartPad 2 is a bit better but still)... and in todays world of mobile phones and SBC to me is just crazy the lack of perfomance...

    Thats a general problem today. Hardware redesign is always considered expensive and software nearly costs nothing in many managers minds. Hence the effort that software has to come up with is never considered in the initial developing process. Even worse if it does not work as intended it is always the software guys fault because hardware is out of the focus by then 😤

    Quote from sjx

    With an update to KSS V5.6 and SafeOP2.2,

    you have the possibility to change in the definition from cartesian Workspaces beetween $world and $robroot.

    KL is integrated.

    Would that require any updates to the SafeRDC? Or would this be a pure software upgrade?

Advertising from our partners