What means the error message: C204A1 “Path sanity check: Sudden change in target position”
I really cannot make sense from this warning. The bad thing is:
Shortly after I get an error: “Safety Mode changed to Protective Stopped”
What can I do to avoid this warning/error?
The Service Manual doesn’t explain much more than “sudden change in target position”. For my understanding, this means the robot tried to reach a target position that is too far away to reach within a defined time slot or was changed, e.g. collision, while moving(lower level servoj command).
I also had this error after collisions.
I think most of the error messages are odd and do not refer to the specific problem. I got used to it but i think this should be improved…
Thank you Michael!
I have this error in the simulation (!) - no collision, no external influence at all. I do not define a time slot in my “movej” command, but only acc, speed and blending. The only way I found to avoid this error is to set the blending for this one “movej” command to zero. But this makes no sense to me.
My local support guy tried to explain me as areason for this error, that local variables used as waypoints are suddenly changed in the script (I do not use periscope, but scripting and I do a lot of calculation to get a waypoint). But I can’t make sense of this point of view.
is it possible that your calculated waypoints have a overlapping blend while moving? do you calculate them while moving? can i see the script code?
No overlapping blend, I think. this gives a different error message. I indeed calculate the next points while moving. The script is pretty complicated. But I try to give you an idea of what I am doing with a simplyfied excerpt (trying to keep the essential portions):
This piece of script does the movement:
#some constants:
global FaceDown = p[0,0,0,PI,0,0]
global PutDistance=0.1 # 10cm
local Angle = 3.14159/4
local InFrontOfBox = p[0.15, -0.1, PutDistance, 0, 0, 0]
local StartPose = pose_add( InFrontOfBox, FaceDown)
local StartingPose = pose_add( pose_add(InFrontOfBox, p[0, 0.1, 0, 0,0,0]), FaceDown )
local SwingHerePose = pose_add( pose_add(InFrontOfBox, p[0.0, 0.05, 0, -Angle, 0, 0]), FaceDown )
local SwingTherePose = pose_add( pose_add(InFrontOfBox, p[0.0, 0.3, -PutDistance/2, Angle, 0, 0]), FaceDown )
# the SAxPTP basically results in a movej with the corresponding joints vector (see below):
SAxPTP( StartPose )
SAxPTP( StartingPose )
SAxPTP( SwingHerePose )
# I need to set Blend to zero (otherwise error: "sudden change in target position" in the next SAxPTP)
local OldBlend = CurPTPBlend
CurPTPBlend = 0
SAxPTP( SwingTherePose )
CurPTPBlend = OldBlend
SAxPTP(StartPose)
Note the line “CurPTPBlend=0”. If I comment out this line, I get the error, while it is working, if I leave the line active. I have chosen the CurPTPBlend to be 1 cm:
global CurPTPBlend = 0.01 # 1cm
SAxPTP does something with a 7th axis and then a goes to function “PTP”, which is basically a “movej” (see last line). But I try to find a joints vector, which I can accept:
def PTP( ToPose ):
#<some calculation to find a good myQNear>
local ToJoints = get_inverse_kin( ToPose, myQNear )
#<maybe some more calculation to find a good myQNear>
ToJoints = get_inverse_kin( ToPose, myQNear )
#<additional calculations on ToJoints to make it acceptable for me>
local FromPose = get_forward_kin()
local FromJoints = get_target_joint_positions()
Debug( "PTP-Pose: " + to_pose_str(ToPose) + " ->Joints: " + to_joints_str(ToJoints) )
Debug( "frm-Pose: " + to_pose_str(FromPose) + " ->Joints: " + to_joints_str(FromJoints) )
movej( ToJoints, a=CurPTPAcc, v=CurPTPSpeed, r=CurPTPBlend )
end
That’s it.Quite some portion of code, but I think, not too difficult to understand. I replaced some calculation by the comments “<…>” to make the code piece shorter.
The resulting logging looks like this (note the lines with “C204”):
12:01:38.983 BigPose=[ 150mm /-800mm /600mm /-0.000152° /0° /-0° ] 7=450mm SmallPose=[ -300mm /-800mm /600mm /-0.000152° /0° /-0° ]
12:01:38.984 PTP-Pose: [ -300mm /-800mm /600mm /-0.000152° /0° /-0° ] ->Joints: [ 57.683116° /-69.591028° /97.950747° /-118.359848° /90.000081° /32.316884° ]
12:01:38.985 frm-Pose: [ 401.632217mm /601.48701mm /992.970922mm /-0.191059° /0.209549° /0° ] ->Joints: [ 222.334672° /-88.486855° /80.052865° /-81.282435° /89.999888° /-132.334672° ]
12:01:43.712 BigPose=[ 150mm /-900mm /600mm /-0.000152° /0° /-0° ] 7=450mm SmallPose=[ -300mm /-900mm /600mm /-0.000152° /0° /-0° ]
12:01:43.713 PTP-Pose: [ -300mm /-900mm /600mm /-0.000152° /0° /-0° ] ->Joints: [ 60.987276° /-61.528116° /85.898959° /-114.370975° /90.000074° /29.012724° ]
12:01:43.714 frm-Pose: [ -290.531525mm /-803.431402mm /601.636895mm /-0.000151° /-0.000002° /-0° ] ->Joints: [ 58.357763° /-69.668699° /97.874992° /-118.20642° /90.00008° /31.642237° ]
12:01:44.115 BigPose=[ 150mm /-850mm /600mm /-45.000114° /0° /-0° ] 7=450mm SmallPose=[ -300mm /-850mm /600mm /-45.000114° /0° /-0° ]
12:01:44.117 PTP-Pose: [ -300mm /-850mm /600mm /-45.000114° /0° /-0° ] ->Joints: [ 61.923169° /-54.494834° /79.454566° /-156.382361° /109.439061° /20.66606° ]
12:01:44.117 frm-Pose: [ -300.681549mm /-889.56923mm /600.462259mm /-0.000152° /0° /-0° ] ->Joints: [ 60.636334° /-62.384495° /87.179005° /-114.794642° /90.000075° /29.363666° ]
12:01:45.023 7th axis goes to: 450
12:01:45.023 BigPose=[ 150mm /-1100mm /650mm /44.99981° /0° /-0° ] 7=450mm SmallPose=[ -300mm /-1100mm /650mm /44.99981° /0° /-0° ]
12:01:45.024 PTP-Pose: [ -300mm /-1100mm /650mm /44.99981° /0° /-0° ] ->Joints: [ 64.125541° /-50.959651° /51.845493° /-48.906657° /72.02627° /18.930138° ]
12:01:45.024 frm-Pose: [ -298.037408mm /-850.671169mm /606.358957mm /-41.698852° /1.07528° /-0.351114° ] ->Joints: [ 61.789538° /-55.423549° /80.312428° /-153.456596° /107.302283° /21.748594° ]
12:01:46.937 :: -2 :: C204A1:6 :: null :: 2 :: :: :: 0
12:01:46.937 BigPose=[ 150mm /-800mm /600mm /-0.000152° /0° /-0° ] 7=450mm SmallPose=[ -300mm /-800mm /600mm /-0.000152° /0° /-0° ]
12:01:46.938 PTP-Pose: [ -300mm /-800mm /600mm /-0.000152° /0° /-0° ] ->Joints: [ 57.683116° /-69.591028° /97.950747° /-118.359848° /90.000081° /32.316885° ]
12:01:46.938 frm-Pose: [ -306.648104mm /-1095.102861mm /643.815867mm /41.956719° /-1.281293° /-1.30978° ] ->Joints: [ 63.952646° /-51.235684° /53.746496° /-53.011899° /74.461284° /19.0669° ]
12:01:46.943 :: -3 :: C204A1:5 :: 3 :: 1 :: :: :: 0
12:01:47.035 bullmer :: Program bullmer stopped
Can you see any potential problems?
i can’t see the problem yet. do you log your Acc, Speed and Blend? The Last 2 steps, right before the Error are compared to the others quite huge (esp. axis 4) but shouldn’t be a problem if the speed, acceleration and blend matches the safety limits.
Actually the last steps are the “smaller ones”, at least they seem so, because there is only a small step in X/Y/Z.
I am actually working with “robot limits stage 2” (not “most restricted”, but one lower; with normal Power limit 200W).
I set acc, speed and blend like this:
global CurPTPAcc = d2r(300) # 300°/s^2
global CurPTPSpeed = d2r(150) # 150°/s
global CurPTPBlend = 0.01 # 1cm
global CurLINAcc = 10 # 10m/s² (~1g)
global CurLINSpeed = 5 # 5m/s
global CurLINBlend = 0.005 # 5mm
“PTP” are for point-to-point moves (movej) and “LIN” are for linear moves (movel).
I never change them (except for the one situation to avoid the error)
Also, I assume, that the robot controller will not trigger an error, if these values are too high, but automatically reduce them to the safety limits.
There could be a couple of reasons, mainly there are some inconsistencies between the position and speed of the robot. Possible cause can be sudden changes to the target position, sudden stops, invalid blend radius, or software bugs. What version of PolyScope are you running?
You can try avoiding controlling the robot from different threads, careful with any events, or continuous if statements. Avoiding sudden stops, you can use a stopj() command, you should also avoid wait instructions following blended way points.
On first view i guess the speed and acceleration is too high for the safety config (unless its not customized) i will check this tomorrow.
i would also try to use servoj instead of movej as it moves the robot in a defined time slot and smoothly stops its trajoctory if you call another servoj command. You will need some additional calculations to achieve this, e.g. path distance to calculate the time slot. Therefore, if the servoj path diiffers much from the movej path you can assure that the movej path is ‚planned too hard‘.
i tried the LIN parameters with a dummy movel command and got the same Error using the same Safety Configuration. On second attempt it even freezes URSim 
The PTP parameters tho should be fine. I would suggest to log all waypoints and replay them in order, playing around with the params until it gets more clearly which specific param causes the error.
Hi all!
All of the above messages made no real sense to me, so I decided to go on with my workaround (using Blend=0 in the one situation). But the error “came back”. And this time I could isolate it. This is my example program:
global CurPTPAcc=d2r(300)
global CurPTPSpeed=d2r(150)
global CurPTPBlend=0.01
global CurLINAcc = 10
global CurLINSpeed = 5
global CurLINBlend = 0.005
local Wait = 0
local ShowError = True
local Text = "Error will not come: i="
if( ShowError ):
CurLINAcc=1
CurLINSpeed=1
CurLINBlend=0.005
Wait = 0.002
Text = "Error will come: i="
end
def Movej(Joints):
movej( Joints, a=CurPTPAcc, v=CurPTPSpeed, r=CurPTPBlend )
end
def Movel( Pose ):
movel( Pose, a=CurLINAcc, v=CurLINSpeed, r=CurLINBlend )
end
textmsg("start now")
local i=0
while( True ):
Movej([1.855755, -1.906144, 2.179251, -1.843495, 1.566944, -0.285978])
Movel(p[0.3, -0.399979, 1.221212, -0.000004, 0.000055, 3.141559])
sleep(Wait)
Movel(p[0.3, -0.399983, 1.121212, -0.000004, 0.000055, 3.141559])
textmsg( Text + to_str(i) )
i = i+1
end
textmsg("end now")
halt
The loop runs 4 times at most, then shows an error C204A2 before the second movel command. If you set the variable “ShowError” to False, it will run forever (I never got an error). You can even try it in the simulator. My simulator has version 5.3.1.64192(Apr 01 2019).
The important thing seems to be the sleep-command. Without it (or with waiting time 0) I can drive much faster and will not get an error. With a waiting time >= 0.002 I get the error pretty soon.
No idea, why…
you should avoid using Sleep times after blended Waypoints. The Purpose of Blends is to avoid the short stop on the waypoint. Using sleeps will affect the blend path as it turns half the blend circle, stops and immediately tries to jump to the waypoint causing the error.
Hello Michael!
This at last is an explanation, which I can understand and also makes sense to me.
Even if I expect, that there should be a “fallback” (if there is no next waypoint, then goto the waypoint itself, not only to blending distance to the waypoint). But of course, if the robot only goes to the blending distance, waits there and the next waypoint is defined, then it looks like “a sudden change in target position”.
I will try to edit my source with this knowledge and I hope, this will fix my problems. This might be not so easy as I calculate my waypoints “on the fly” and it might never be really clear, how long this calculation lasts (and when the next waypoint will be available or if there is a break)
Thank you!