SafeMove -- Speed violation in Teach mode

    I think I'm missing something regarding the SafeMove speed supervision in Teach mode. My SafeMove Pro setups have no speed supervision set up -- I'm only using Position Supervision. But while all my programs run fine at 100% in Auto, in Teach, for some motions I have to reduce playback speed to 50% or even 25% in order to avoid being constantly stopped by SafeMove Speed Supervision errors.


    The setting "Max Speed In Manual Mode" is set to 250, as one would expect. But even though the robot shouldn't be able to move the TCP faster than 250mm/sec in Teach mode, I'll still get these faults. There is only one permanently-mounted tool, so no tool-changing issues involved.


    This mainly seems to happen when I'm running a move that combines motion and rotation -- if I'm making a major joint move to "unwind" the wrist while also moving the robot rapidly through the air (going Home after a weld sequence, for example), this seems to be when the error is most likely to occur. My best guess is that, despite the inherent 250mm/s limit of the robot, some of these moves are getting the TCP to something above that limit, and SafeMove is catching it. Annoyingly.


    That brings me to Speed Supervision Points. The SafeMove manual doesn't really explain them very much, but my takeaway is that, while the motion controller only monitors that active TCP, the SafeMove controller can monitor multiple "TCPs" simultaneously and throw a fault if any of them exceed whatever Speed Supervision limit is active. Which seems like it would make the robot even more prone to throwing these faults.


    One thing I'm unclear on: in the SafeMove config, does the "Tool Data" entry automatically create a Speed Supervision point? The labelling is a bit ambiguous, but it from what experiments I've been able to do, it does seem this way -- I know I've been able to reduce the Safety Speed errors by changing the "TCP" in SafeMove back to 0,0,0. But that's probably not kosher for a production system. But if I set the SafeMove "Tool Data" to match my real TCP, I get more of these errors, which seems backwards.

    (also, does SafeMove use the Load Data setting to adjust stopping distances for inertia?)


    So, asking the people with deeper SafeMove know-how than I have: is this just something I have to live with, or am I missing some key insight? This is an annoyance, it has no effect on production operation, but when I'm in a rush trying to test path changes in Manual, it gets really annoying.

    Don't know about the safemove aspect, but here is a really hacky possible RAPID work-around. :thinking_face:


    Create a virtual input(s) and a output(s) on the virtual bus and cross connect the outputs to the inputs for affecting axis speed limitation. E.g. vdi_SpeedLimAx6, vdo_SpeedLimAx6. Also, there will need to be a system input, or SOME system inputs, parameter added for the Limit Speed action.


    Next find your problem code spot and right before it insert this.


    IF OpMode()<>OP_AUTO THEN

    SetDO vdo_SpeedLimAx6

    SpeedLimAxis ROB_1, 6, 20;

    ENDIF


    Maybe make it Procedure with data or a function ...?


    Yes, it is advised to reset the slowdown, by resetting the output, somewhere in your code, say in a housekeeping routine.


    As indicated above it is a hacky solution.


    Or wait for the better answers wiser techs than I will suggest. :smiling_face:

    Edited 2 times, last by SomeTekk ().

    Quote from SomeTekk

    As indicated above it is a hacky solution.

    I love me a good hack. :yesyesyes:


    But since I won't own these robots in production (I'm just the integrator), I probably should try using that. With my luck, I won't get a chance to remove it and then the customer will :mad: :bur2: :AR15firing:


    Still, that's an interesting bit of code. I'll have to keep that in my notes for possible future use.

    I would suggest hunting around to see if you are tracking the elbow in safemove. It's possible that what's happening is that the elbow is moving faster that 250 during the rotation moves. You may be able to turn it off.

    Quote from SharplesR

    I would suggest hunting around to see if you are tracking the elbow in safemove. It's possible that what's happening is that the elbow is moving faster that 250 during the rotation moves. You may be able to turn it off.

    I didn't realize SafeMove could track elbow velocity. Where is that setting located? I have Upper Arm Geometry active and tracked, but I don't see anyplace to turn elbow velocity monitoring on/off. The only mention of the Elbow in the SafeMove manual is talking about the elbow offset base on robot model.

Advertising from our partners