Choice of proper S and T before SPLINE execution

    Hello,

    I have faced situation when robot stopped and reported for "software limit reach" during SPLINE motion.
    Some facts about motion I ask robot to perform:
    1. It's quite long (~3000mm) almost straight motion. Motion can consist of 1-5 segments, depending on the required complexity of path.

    2. First point if motion is always PTP (with defined S and T). Due to motion nature, the selection of S and T parameters depends on the Z coordinate of the base (essentially, the height of the base), and the movements are performed relative to this base. So, like, from particular Z of base we are changing from 2 43 to 6 59.

    3. For single segment motion single SLIN used, for larger amount of segments combination of SLIN-SPL (SPL here makes transitions between SLIN more smooth) are used. Any amount of segments are packed into SPLINE in code. For example:

    4. Amount of segments is always different. As well as positions of each point (coordinates are calculated externally and sent to robot):

    • X coordinate changes along mentioned 3000mm
    • Amplitude of the possible change in the Z coordinate is 150mm
    • Angle B can vary from -5 to 5 degrees
    • A,C and Y are constant

    Single segment motion coordinates example:

    Code
    LINE_SCAN_POINTS[1]={X -115.000,Y 2003.44,Z -529.840,A -90.0000,B 2.58000,C 0.0,S 2,T 43}
LINE_SCAN_POINTS[2]={X 3130.00,Y 2003.44,Z -607.700,A -90.0000,B 2.58000,C 0.0,S 2,T 43}

    Are there an option to check the possibility of executing a SPLINE motion before performing it? Or, may be, force robot to do additional checks during SPLINE planning, so it can report that there will be a problem?

  • HawkME March 26, 2023 at 4:45 AM

    Approved the thread.

    Unfortuntly there is no possibility to check this beforehand. For continous path movements (motions that are not ptp) this is difficult in general because the exact axis positions are created more or less on the fly when executing the motion using a shortest path strategy from interpolation cycle to interpolation cycle. Even though compared to old motion types spline actually plans the trajectory based on a axis spline calculated from the Cartesian geometry this axis spline is only a rough approximate of the exact geometry due to performance issues. So when the velocity profile is created you still can not check beforehand conditions like software limits. What maybe can be done is to activate cp_statmon a monitoring function that checks whether the status and turn at the end position after execution of the spline will be the ones programmed with the target position. So if you would not want to execute the spline set status and turn of the last target in the splineblock to the same values of your preceding ptp and activate $cp_statmon. But I an not totally sure if I remembered this totally correct. The robot might still execute and stop at the end of the spline but you could try it out.

    Fubini

    If status changes it explicitly implies you are passing over a singularity. PTP would be immune against these but I´m betting you cannot use that

    1. A mechanical solution would be to move or tilt something until this does not occur anymore.

    2. If the move ends at a changed status you should be able to catch this with the INVERSE() function. If it is such a move that you pass over a singularity but status at the end flips back to original... I know of no other way than splitting it to smaller segments and passing it thru INVERSE to see if it is reachable or not.

    3. I´ve heard rumors that ON_ERROR_PROCEED should be applicable to motions from kss 8.5 onwards, but I have not tried this. System integrators manual for KSS 8.5 says that atleast non spline motions would be covered by it. So in principle you could test to go to a point LIN and catch possible errors with ON_ERROR_PROCEED and e.g. try the same move with a ptp or go to another point..

    Edit: 2 & 3 would require that you ditch the splineblock

    Edited once, last by Hes (March 27, 2023 at 3:05 AM).

    Quote from Daniil1994

    I have faced situation when robot stopped and reported for "software limit reach" during SPLINE motion.

    On which axis? It would be helpful to have the exact error message and error code number. Along with KSS version. What does the motion look like physically? What are the axes doing? Does the robot actually hit the axis limit physically, or is this error popping up predictively?

    If it's A4 or A6, that implies you're going through a singularity and over-rotating the wrist. Your best way to avoid this might be to change your EOAT mounting so that your path doesn't move A5 near 0.

    As Hes mentioned, you might be able to use INVERSE to pre-check the points against the axis limits, but you won't be able to check the Spline path between the points that way.

    Quote from SkyeFire

    On which axis? It would be helpful to have the exact error message and error code number. Along with KSS version. What does the motion look like physically? What are the axes doing? Does the robot actually hit the axis limit physically, or is this error popping up predictively?

    1. 6-th axis

    2. Standard Workspace error message about reaching software limit switch on the way to "point".
    3. Yeah, robot hit the axis limit physically. Which mean that I have chosen wrong S and T for begging of movement.

    Quote


    If it's A4 or A6, that implies you're going through a singularity and over-rotating the wrist. Your best way to avoid this might be to change your EOAT mounting so that your path doesn't move A5 near 0.

    Yeah, you are totally right here. Before using SPLINES I tried to use LIN but I had problems with dynamic limits when robot was moving A5 close to 0. So I have switched to SPLINES.

    Unfortunately, I am unable to adjust the mounting angle of the tool, as it needs to operate across a wide range of base Z levels. If I were to install an additional console that creates an angle between the 6th axis flange plane and the tool plane, there would be a Z level that would cause A5 to take a complementary angle to the console angle.

    I'll try to work out ON_ERROR_PROCEED, $cp_statmon and INVERSE solutions.
    By the way, do INVERSE calculation stop advance run pointer?

    Yes, INVERSE() should have no effect on the ARP. However, it is vulnerable to the ARP -- INVERSE() relies on $BASE and $TOOL, so you need to ensure that when INVERSE() is called, those variables are correct.

    So, you might be able to try checking your path points with INVERSE() using a temporary E6POS copy of your start point, trying different S&T combinations until you (hopefully) find one that doesn't return an ERR_STATUS above 0.

    Quote from Daniil1994

    Before using SPLINES I tried to use LIN but I had problems with dynamic limits when robot was moving A5 close to 0. So I have switched to SPLINES

    Well if you can accept that the linear speed is not constant and your previous LIN trials resulted in overspeed. You can get around this by setting $CP_VEL_TYPE to #VAR_ALL

    This will allow you to pass over the a5 singularity as long you dont go exactly dead center thru it or do any other nasty stuff. Beware that the singularity that previously stopped the robot before anything happened, will not do that anymore.. eg. A4 might be flipped when you reach the endpoint.

Advertising from our partners