Within blend distance?

    Hello

    I have been looking at system variables for Kuka robots.

    $ACT_ADVANCE will tell me how many points are currently planned in the main run.

    If there is only one point planned, is there then a way of telling whether the robot is within the blend radius of this point? I am having some problems with a KRC4 robot (KSS v8.3.20), and I am pretty sure that the reason is that the robot is within the blend radius of the final point in the queue, when I add more points to the queue. The points are transmitted from a PC. If I tell the robot to stop completely (wait sec 0) before moving to the next points, it works. But this is not an option in this project, due to cycle time limitations. The problem annoys me to no end - the program has been working perfectly on many KRC2 robots for many years, but on KRC4 we have these problems.

    /RoboticsMan

    Quote

    If there is only one point planned, is there then a way of telling whether the robot is within the blend radius of this point?

    Lookup ENUM MOVE_STATE $MOVE_STATE with

    ENUM MOVE_STATE PTP_SINGLE, PTP_AP01, PTP_AP02, LIN_SINGLE, LIN_AP01,LIN_AP02, CIRC_SINGLE, CIRC_AP01, CIRC_AP02, MOVE_EMI_SINGLE, SPLINE_SPL, SPLINE_LIN, SPLINE_CIRC, SPLINE_PTP, SPLINE_UES, SPLINE_UES_PTP, NONE

    *_SINGLE indicates you are still before blending.
    *_AP01 indicates you are inside the first half of blending (Approximation)
    *_AP02 indicates you are inside the second half of blending (Approximation)

    Since for spline there are no longer blending halfs *_UES indicates you are inside blending.

    Fubini

    Edited once, last by Fubini (August 29, 2017 at 5:55 PM).

    Quote from Fubini

    Lookup ENUM MOVE_STATE $MOVE_STATE with

    ENUM MOVE_STATE PTP_SINGLE, PTP_AP01, PTP_AP02, LIN_SINGLE, LIN_AP01,LIN_AP02, CIRC_SINGLE, CIRC_AP01, CIRC_AP02, MOVE_EMI_SINGLE, SPLINE_SPL, SPLINE_LIN, SPLINE_CIRC, SPLINE_PTP, SPLINE_UES, SPLINE_UES_PTP, NONE

    *_SINGLE indicates you are still before blending.
    *_AP01 indicates you are inside the first half of blending (Approximation)
    *_AP02 indicates you are inside the second half of blending (Approximation)

    Since for spline there are no longer blending halfs *_UES indicates you are inside blending.

    Fubini

    Thank you very much for your reply! It is always nice to learn about undocumented system variables [emoji1]

    Unfortunately it does not solve my problem. Let's say I have a linear movement to p1, followed by a ptp movement to p2. Let's say the blend radius at p1 is 100 mm. If the robot moves too close to p1 before p2 is added to the queue, will stop instead of blending. This makes sense. However, it will also show a message that the user has to acknowledge: "CP/PTP approximate positioning cannot be carried out". This problem I never had on the KRC2.
    I cannot solve this problem using $MOVE_STATE, because $MOVE_STATE will remain LIN_SINGLE until the robot stops.
    So what I actually need to know is whether the robot would have started blending, if the next point was available. I would have used $DIST_NEXT, but that does not work if I go from a PTP movement to a LIN movement.

    /RoboticsMan

    Sendt fra min D5803 med Tapatalk

    Im trying to prevent that the robot sometimes (depending on timing) stops with an error message (CP/PTP approximate positioning cannot be carried out), and at the same time I want it to blend (i.e. not stop!) if it is at all possible. In the current implementation I have to stop in order to be sure, whenever I have received the next coordinates from the PC. I did not have to do that on KRC2. It is not easy to "fix the path", because the path is generated by the software on the PC.

    Strange that this behaviour did not occur on KRC2 because Oldmotion (PTP, CIRC, LIN) is not changed between KRC2 and KRC4. But let me elaborate a bit more on the reason why message no 1491 "CP/PTP approximate positioning not feasible" can happen. This only depends on the programmed geometry. You program must look something like

    PTP/LIN XP0
    LIN/CIRC XP1 C_DIS/C_VEL/...
    PTP XP2

    Since the movement to XP1 is a LIN the calculated geometry and velocity profile are in cartesian space. More precise for the geometry a programmed status and turn are ignored. Status is taken from the status at the end of the motion command before XP1 and turn is calculated implicitly by interpolating the path and always choosing the axis angles closest to the axis positions of the previous interpolation cycle. Hence at planning stage in advance run neither status and turn are already known and how the robot has to move his axes to achieve the LIN is also unknown. Moreover since the blending arc is a ptp movement in axis space axis angles and velocities at the beginning and the end of the blending arc are needed to plan the approximation move in advance run. Due to this problem the advance run is implicitly reduced to length 1 (seeable in $ACT_ADVANCE) to get a closer picture on what the status and initial turn will be at interpolation/execution time. But still it is some sort of guessing. Using this estimated status and turn by using robot inverse kinematics it is possible to calculate estimated axis angles and velocities at blending start and finally calculate the blending move with the estimated axes values. This blending move is only valid if at execution time the guess was correct otherwise you are not able to run this blending arc. Hence reaching the blending start position interpolation checks if estimated axis values and current axis values match. If this is not the case due to bad estimation of status and turn message no 1491 is issued and the robot controller does not switch to the blending arc but keeps on going to the direct path to XP1.

    So basically I hope this answers your question: the robot controller itself only detects the problem on passing the blending start, so how should you detect it earlier.


    By the way this again is one of the many situations that are suboptimal in old motion but where considered by KUKA in the design of spline. Hence in spline this problem is no longer present, because of a total different approach on how blending is done.

    Fubini

    Hello

    Thank you for your answer! It is always interesting to know more about what is "going on behind the scenes". But why does this error pop up if we receive the next point too late? This should not change the estimate of the joint values at the start of the blend, or should it?
    My program looks something like this:

    Code
    PTP XP1 C_DIS
continue
waitvar = false
trigger when distance =0  delay = 600 do waitvar =true
LIN XP2 C_DIS 
continue
wait for waitvar == true
PTP XP3 C_DIS

    Depending on the delay, I will get the error at the start of the blend between XP2 and XP3. Does the delay change the estimate of the joint angles?

    So actually, what I want to know is not whether the error will occur - I want to know how close the robot is to the start of the blend, when the next point arrives. If it is too close, the error might occur. If this is the case, I can prevent the error by inserting a "wait sec 0" between the two points.

    Related to this problem I have also had another problem where a trigger (like the one in my test program) is never "fired" under certain circumstances. In this case it would "wait for waitwar== true" forever. I also think this is related to blends and the arrival time of the next point. I also never had this problem on KRC2.

    /RoboticsMan

    Hm... what's your $ADVANCE value? The default is 3, which means that the evaluation of the WAIT FOR could take place all the way back at XP1.

    The time/distance is the key here. Basically, if the advance run pointer gets to the WAIT FOR before WaitVar is True, then the path planner cannot approximate the motion you'll get either the error, or a brief stoppage at XP2. If you are dynamically feeding motions to the robot from an external source, the only way to avoid this is to ensure that the reception stays far enough ahead of the advance run pointer.

    Using CONTINUE statements can also be dangerous, since it can cause logic evaluations so far ahead of the main run, and can be inconsistent in timing. Generally, when I've needed to do things like this, I use TRIGGER calls to subroutines, and put my WAIT FOR logic, with CONTINUES, inside the subroutine. That explicitly ties the timing of the WAIT FOR evaluation to a specific point.

    Quote

    Hm... what's your $ADVANCE value?

    Advance is always 5 in our program. The whole program is written so that it doesn't "get ahead of itself". "wait for" and "wait sec 0" is used where it is needed. We have used various iterations of this program for almost 10 years, so most of the problems are solved by now :winking_face:

    Quote

    Generally, when I've needed to do things like this, I use TRIGGER calls to subroutines, and put my WAIT FOR logic, with CONTINUES, inside the subroutine. That explicitly ties the timing of the WAIT FOR evaluation to a specific point.

    A "wait for" in a sub routine called by a trigger? I have never thought of that. But how does that work? Where does the robot stop to wait for the condition??
    The "wait for" in my example was just used to simulate the effect of a coordinate that arrives in the last moment.

    Having the WAIT FOR (with a CONTINUE) inside the Trigger-called subroutine works just as if you had the CONTINUE-WAIT FOR in the main program, with the exception that there's no look-ahead evaluation by the advance pointer. Instead, the evaluation (and the Wait) take place only when the Trigger makes the call. I used it a lot for zone interference calls when I needed to avoid pausing at the boundary (which would be caused by looking to far ahead), but still needed a safe check of the zone clearance before entering.

    As far as the program "getting ahead of itself" -- it is, somewhere. That's what's causing those approximation errors. If the advance pointer was never getting blocked, you would never see those errors.

    Quote

    Having the WAIT FOR (with a CONTINUE) inside the Trigger-called subroutine works just as if you had the CONTINUE-WAIT FOR in the main program, with the exception that there's no look-ahead evaluation by the advance pointer. Instead, the evaluation (and the Wait) take place only when the Trigger makes the call. I used it a lot for zone interference calls when I needed to avoid pausing at the boundary (which would be caused by looking to far ahead), but still needed a safe check of the zone clearance before entering.

    I still don't quite understand it - I guess I will just have to try it by myself :smiling_face:

    Quote

    As far as the program "getting ahead of itself" -- it is, somewhere. That's what's causing those approximation errors. If the advance pointer was never getting blocked, you would never see those errors.

    I will politely disagree! I'm convinced the problem is that the next coordinate arrives too close to the blend radius of the previous point. I think the problem would be the same if $ADVANCE was set to 1. The motion planner simply cannot handle the late arrival of the next coordinate correctly. It has not been a problem on KRC2 for almost 10 years, so why am I seeing this on KRC4 now? It must be an issue that has been introduced in the newer versions of KSS. On the KRC2 the robot simply stopped at the point and continued afterwards, when it was too close to the end-point to perform the blend. Maybe this is not the desired behavior in all cases, but it certainly is in our case :smiling_face:

    Oh, no, that is due to the system variable $STOPNOAPROX, like I mentioned above. That controls whether the robot stops and faults when an approximation error occurs, or just throws a status message and keeps on going (albeit non-continuously). That's not a KRC4/KRC2 thing, that's a configuration thing.

    As for points too close together... well, I've done some pretty closely-spaced points (100+, spaced at ~0.5mm, trying to do a Spline-type motion before SPLIN was available) with CONT over the years, without running into that issue. So I can't say I've studied it exhaustively, but I've only ever seen Approximation errors caused by timing (or things like a CONT on the final motion of a program, but I'm sure that's not the case here).

    Quote

    Oh, no, that is due to the system variable $STOPNOAPROX, like I mentioned above

    Wait, what? The way I use $STOPNOAPROX, is to find out when ANYTHING stops the advancepointer. So I set $STOPNOAPROX to TRUE, and when the advance pointer comes to a statement like "$OUT[241]=TRUE" and is stopped, the robot will stop immediately, and show an error message that must be acknowledged. Using the "caller stack" window, I can see which line stopped the advance pointer, and "fix" this by adding CONTINUE.

    The stops I have seen on KRC4 are most definitely not related to $STOPNOAPROX. I have used $STOPNOAPROX to try to learn more the problem, but it was FALSE when I saw the problems. And leaving it set to TRUE doesn't make sense, obviously. Then I would have to acknowledge all the time!

    Quote from SkyeFire


    I used it a lot for zone interference calls when I needed to avoid pausing at the boundary (which would be caused by looking to far ahead), but still needed a safe check of the zone clearance before entering.

    A couple of questions:

    1) How do you have a safe-zone-check in a subroutine which is called from a trigger? I just tried on our KRC2, and no, the "wait for" in a subroutine from a trigger does not stop the robot, even when the condition fails. This means that the robot would always move into the "safe" zone?!

    2) Why would looking far ahead cause a stop at the boundary?
    If I have a program like this:

    Then it will not cause a stop between p3 and p4 unless the motion-pointer gets to the start of the blend-radius at p3 before $in[31] switches to TRUE.

    If I put the "$out" and "wait for" statements into a subroutine called from a trigger between p3 and p4, then the robot will happily move from p3 to p4 without waiting for permission.
    Or maybe I misunderstood you?

    Quote from RoboticsMan

    Wait, what? The way I use $STOPNOAPROX, is to find out when ANYTHING stops the advancepointer. So I set $STOPNOAPROX to TRUE, and when the advance pointer comes to a statement like "$OUT[241]=TRUE" and is stopped, the robot will stop immediately, and show an error message that must be acknowledged. Using the "caller stack" window, I can see which line stopped the advance pointer, and "fix" this by adding CONTINUE.

    The stops I have seen on KRC4 are most definitely not related to $STOPNOAPROX. I have used $STOPNOAPROX to try to learn more the problem, but it was FALSE when I saw the problems. And leaving it set to TRUE doesn't make sense, obviously. Then I would have to acknowledge all the time!

    Okay, obviously I misunderstood something. I thought you were simply getting stopped by the approximation error message that $STOPNOAPROX suppresses. What's the actual error code you're getting?

    Quote from RoboticsMan

    A couple of questions:

    1) How do you have a safe-zone-check in a subroutine which is called from a trigger? I just tried on our KRC2, and no, the "wait for" in a subroutine from a trigger does not stop the robot, even when the condition fails. This means that the robot would always move into the "safe" zone?!

    2) Why would looking far ahead cause a stop at the boundary?
    If I have a program like this:

    Then it will not cause a stop between p3 and p4 unless the motion-pointer gets to the start of the blend-radius at p3 before $in[31] switches to TRUE.

    If I put the "$out" and "wait for" statements into a subroutine called from a trigger between p3 and p4, then the robot will happily move from p3 to p4 without waiting for permission.
    Or maybe I misunderstood you?

    ...what? With that code, the $IN check will occur when the robot is at P1, or earlier. That's how CONTINUE interacts with the advance pointer -- the advance pointer is always ahead of the main run pointer by $ADVANCE number of motion commands -- if you have I/O commands in between those motions, they break the advance pointer. If you buffer those I/O commands with CONTINUES, then they get executed several motions in advance of where the robot is physically.
    What this means is that, in your example code, if the Clear input is True when the robot is moving from P1 to P2, but then goes False while the robot is moving from P2 to P3, the WAIT FOR has already been passed and evaluated, and the robot blows right through. And if you change the $ADVANCE value, or add/remove points between P1 and P3, the location in physical space where the WAIT FOR is evaluated changes unpredictably. That's why CONTINUEs are dangerous.

    As for how we used TRIGGERs to resolve this... well, it's been a few years -- I'd have to dig up the specific code. But basically, it wasn't just a WAIT FOR inside the Triggered subroutine. Rather, the Zone Entry check would be a Triggered subroutine as the robot neared the last clear position, and inside the subroutine there was a set of IF/THEN or SWITCH statements, liberally coated in CONTINUEs, that checked the zone signal status and would let the robot blow through if the zone was already clear, and only branch into a WAIT FOR or a REPEAT UNTIL if the signal showed the zone was not clear. IIRC, we never put a CONTINUE on the WAIT FOR itself -- the code was structured such that the pointer only ran through the various CONTINUES if the signal already showed a clear condition -- if it didn't, then you branched into WAIT FORs that did not have any continues.
    As I recall, we had a firm rule on that project to never have any CONTINUE statements in the main run of any of the programs, due to some unpleasant incidents. SYN_WAITs were also prohibited.

    The general idea was to eliminate pauses unless an actual zone conflict existed, but avoid the inherent risks of using CONTINUE WAIT FORs in the main run of the program. We were building an entire software architecture for an automotive body shop (from a "blank sheet of paper"), and needed to ensure it was idiot-proof to the greatest extent possible. Future operators might add or remove points almost randomly, so the zone calls had to be immune to $ADVANCE shenanigans. I think we ended up creating an inline form for Zone Entry/Exit points, that folded the TRIGGER into the unseen KRL.

    Quote

    ...what? With that code, the $IN check will occur when the robot is at P1, or earlier. That's how CONTINUE interacts with the advance pointer -- the advance pointer is always ahead of the main run pointer by $ADVANCE number of motion commands -- if you have I/O commands in between those motions, they break the advance pointer. If you buffer those I/O commands with CONTINUES, then they get executed several motions in advance of where the robot is physically.
    What this means is that, in your example code, if the Clear input is True when the robot is moving from P1 to P2, but then goes False while the robot is moving from P2 to P3, the WAIT FOR has already been passed and evaluated, and the robot blows right through. And if you change the $ADVANCE value, or add/remove points between P1 and P3, the location in physical space where the WAIT FOR is evaluated changes unpredictably. That's why CONTINUEs are dangerous.

    Well ok, I have to admit that it was not the best example. Here the assumption was that the input will be false until the robot asks for permission to enter, and once it has seen the signal (and acknowledged, which is not shown in the example), the signal would be reset. It is not a "area is free" signal as much as a "the area has now been allocated to YOU" signal.

    I understand that you used a trigger to ask for permission to enter, but there must have been some sort of "wait for" in the "main program" also, i.e. outside the subroutine. The sub routine called from the trigger will not stop the "main program" on its own, no matter the amount of "wait for" you have in the subroutine. It runs in a separate thread, and I guess you dont even need any "continue" in the sub routine? Perhaps the main run could be stopped with an interrupt from the sub routine, but that isn't pretty.

    I do understand your concerns about making the code fool-proof. In the projects I have worked on, this has not been a consideration. We have had enough headaches even without having to worry about accidental "saboteurs" :smiling_face:

    Quote

    What's the actual error code you're getting?

    I dont remember the error code, but the message is something like "CP/PTP approximate positioning cannot be carried out" and NOT "CP/PTP approximate positioning not feasible". It is not just a warning, it is an error that the user has to acknowledge.

    not trying to hijack this thread(some interesting stuff in here) but you mentioned feeding those points from an external PC. We have done work where we read from an external text file, but I am wondering if there are other ways you would write those points? I can imagine if it was just a few points, you could map I/O but I am assuming that is not what you are doing. Is there another way to change those points remotely?

    Quote from wes_mcgee


    not trying to hijack this thread(some interesting stuff in here) but you mentioned feeding those points from an external PC. We have done work where we read from an external text file, but I am wondering if there are other ways you would write those points? I can imagine if it was just a few points, you could map I/O but I am assuming that is not what you are doing. Is there another way to change those points remotely?

    The application is bin picking. The points are generated at run-time based on part positions, so they have to be transferred from the pc. We send around 9 via points to the robot in each cycle. Data is transferred via the Kuka Ethernet XML Software. (I don't remember if that is the exact name)

    Sendt fra min D5803 med Tapatalk

Advertising from our partners