UR10e not starting from beginning

After updating to the new polyscope, When I try to start from the beginning of my program, the Waypoint the robot wants to move to is no longer my home position. It is a way point way down in my safe home folder. This is before the program even start to run…

Has anyone ever seen this?

I have checked my home position, it’s correct. I loaded from a backup, both the program and the installation files, still the same issue.

any help greatly appreciated.

What version of Polyscope did you start at, and what version did you update to?

How do you control your safe home program? Does it use an installation variable that may have been manually changed by someone else?

I went from 5.9.1 to 5.11.4

the safe home is based on the TCP location X,Y and Z… so i get the actual TCP then using ifs and elseif to determine what set of moves to safely get home.

but that is after the program start, the issue I am having is before all of that

the move to is a way point from line 243 in my program

that waypoint is in my safe home

why is the program starting from 243?

Can you share a photo that shows the Safe Home Folder from line 194-243? I see you’re gathering info about the current robot position at the beginning of the Safe Home Folder, so at the moment, I would guess an if statement condition is being met to get the robot moving at line 243. Have you made any changes to your tcp that would result in start_pose generating some different values?

You can also PM me your program, installation, variables file, and your robot model if you’d like, and I can take a look at the program in the simulator.

I think your on to something here. I am going to try a few things here, and i will get back to you in a little bit.

I have installation variables for start_z, start_y and start_x and same for rx, ry, rz… these variables seem to be reverting to meet a condition. Like you said…

We might be on the right path here

So my plan did not work. I added a variable assignment after the robot got home in the program. I reset all variables to reflect the home position, in hopes that they would not meet the conditions of the if elseif statements on start. still the after pressing play from beginning the robot want to move to the the way point from line 243.

ElseIf (start_x≤-0.40 and start_x≥-0.58) and (start_y≤0.10 and start_y≥0.0) and (start_z≤0.65 and start_z≥0.50) and (start_rx≤-1.1 and start_rx≥-1.3)
‘Drop top windows recovery.’
Popup: Recover from to window drop off point?
O_60LEFT_RET≔ True
O_60LEFT_EXT≔ False
O_60RIGHT_RET≔ True
O_60RIGHT_EXT≔ False
xUpdateMPLA1≔ True
xUpdateMPLA2≔ True
Call MPLA1_Output_Control
Call MPLA2_Output_Control
If ST60_RIGHTRET and St60_LeftRet
start_pose≔p[0.11164,-0.475,0.13921,start_pose[3],start_pose[4],start_pose[5]]
‘MoveL’
MoveL
TopDevAppr_1
MoveJ
MainAppPoint_1

this is the else if with the waypoint in bold, some moves are commented out as they are not needed

When you start the program, is the robot automatically trying to go to TopDevAppr_1, or are you getting the move into position prompt, and you need to use the “move here” button to get the program running?

Where is the “If ST60_RIGHTRET and St60_LeftRet” statement written? Is it nested inside the ElseIf above, or is it at the same level?

Also, do you happen to use more than one TCP in your program, or have more than one TCP saved in your installation? When you call the get_actual_tcp_pose() function, it will return the pose of the active TCP. Maybe the software update reset the active TCP, so you’re starting your program and it’s returning values that meet the ElseIf requirements, because those values are based on a different TCP in the installation file.

-It is a move into position prompt. so it wants to use the “move here” before even starting the program.

-that if is nested under the else if, so it is only seen if conditions are met

-only one TCP saved in the installation.

I do not understand why the move to position, before the program starts is that waypoint. The move to position should be the saved home position, correct?

The “move into position” will be determined by the first fixed waypoint in the program. It would only be the Home position in your installation if you use the Home program node as the first fixed waypoint.

However, if the first waypoint in a program is a variable or relative waypoint, there should never be a “move into position” prompt. From what I can tell, you define start_pose at line 196, and move to it at line 199, so your program should be automatically starting without prompting you to move to TopDevAppr_1.

It seems like for some reason, this variable waypoint is not being properly recognized. Can you delete the MoveL at line 197, then add it back the same way it is set up now?

I have done that, even tried MoveJ. no change. maybe the update doesn’t let you use a variable position as a starting waypoint?

I’m at a loss… before the update it would never prompt to move into position, just would get start from unknown position prompt.

That would be incredibly unfortunate if that is the case, and especially if it was intended (I doubt it was). It would cause me to not upgrade past that version until this is corrected.

On our first UR we had to do this, it was a PITA. The 2nd one we got a few months later was set up differently and used a variable position. We’ve run like this for almost 3 years now and I still remember the day I found out I could do that on the first UR. It was as much of a life-changing event as when I set up a jumper to enable hands-free Freedrive so I could use both hands to move the arm. :+1:

Starting the robot program with a variable waypoint still works on 5.11.4. I verified this on a physical robot and in the simulator.

Using a relative waypoint and setting the 2 positions at the exact same point will do the same thing as well. You can try adding a move to a relative waypoint to the very top of your safe home folder, or even the very top of the before start section to guarantee that it is the first thing being executed.

Otherwise, I think the best bet at this point is to open a support case through myUR and provide the support file there. Someone will be able to fully analyze the program and associated files, and offer additional guidance.

1 Like

Starting the robot program with a variable waypoint still works on 5.11.4. I verified this on a physical robot and in the simulator.

I’m glad this is the case, as it is a function I use regularly. I like being able to control the homing sequences, so if less skilled people are attending the robots I don’t need to worry about them driving into fixtures and such.

I was going though things this morning with a fine tooth comb, and came up with something strange. my variable for my start pose only shows up in my run variable list. Meaning when I go to my installation and go to the variables tab, its nowhere to be found… but it says it exists because I can not make it again using that name

have you seen this before?

That is all normal behavior. The only abnormality would be if prior to the update, start_pose was an installation variable, and after the update, it was no longer there. Did you have other installation variables that are also missing?

Let’s say you have program A with var_A in it, and you flip it between 1 and 2 to control an if statement. Now, let’s say you create program B, and decide you need an installation variable named var_A so the state is saved between program runs. When you go to your installation tab to create var_A, you won’t be able to name it that, because var_A already exists within program 1. While you may recognize the impact this will have, not all users will, and it’s safest for the system to prevent this ability so there isn’t unexpected motion in another program.

Edit: The “variable name already exists” only happens if your open program contains the variable name that you are trying to use to create an installation variable. So with your case, you can do the following:

  1. Create a new program.
  2. Go to the installation tab, and add start_pose as an installation variable. Remember to define it as a pose, p[0,0,0,0,0,0] will work fine. Save the installation file.
  3. Open your existing program that contains start_pose.
  4. You’ll receive the prompt below. Answer “use installation variables”
    image
  5. You may receive a prompt for every instance of start_pose in the program, and maybe for the .old files in the system. Just keep answering “use installation variables”.
  6. If you have other programs on the system that use start_pose, you will go through the same prompt sequence the next time you open them up.

I completely understand that. I don’t think it was an installation variable now that I am digging more, and looking at old programs. This behavior is strange on this UR10e.

I also tried to suppress the waypoint it wanted for the move to position, to see what would happen. Rather then moving to the next waypoint in the program it jumped to the next “else if” and wanted to move to a waypoint in there. When there is a waypoint only a few lines down from the original.

I think I am going to bring it back to 5.9.1 and see how it acts then

Reverted back to 5.9.1 and everything runs as it should…

Just strange

I agree, this is all quite strange.

Again, if you’re able to submit a case through myUR, it would be beneficial for you and UR so we can further diagnose this bug. If you ever have a service event, one of the first recommendations you’ll get is to update your software to the newest version, which won’t do you any good if any updates break your program.

You can also email support.na@universal-robots.com to outline what happened if you don’t yet have myUR set-up.

I have started a ticket with MyUR, we will see

thanks for all your help!!

1 Like

I know it’s off topic but can you please, please, please, elaborate on how I can use two hands to move my robot? Something about jumper? Thanks for the help! Werner

You can wire a toggle switch to an input on the controller, then assign that input for Freedrive use in the IO set-up screen of the installation tab.