1. Have you tried abort all? I have found if you try to open a program in the currently active call stack, it will just auto stuff you into the current program, which is super annoying.
2. Do you have Background Edit, and have you made sure nothing is open in it? This has caused some weird behavior for us as well.
3. What is your start type? PNS, RSR, or Other? Is your PLC trying to start a specific program rather than the one you want?
4. Try putting a break point (wait or pause) in the program you want to be in. This will catch the cursor if the robot it just taking off on a logic path out of the program. Also, try putting a break point in the program it seems to want to be in, see if it is stationary or just reading through too fast to see.
Start type is OTHER. Yes, I ABORT with much frequency. These particular robots are a little different than what I am used to, and I'm guessing that has to do with the Control Reliable deal. When I switch from T1/T2 to AUTO or vice versa, the TP typically tells me I am either entering or leaving INTERLOCK mode. I'm not sure what that means, so if anyone can clarify, that would be good. But I've always just pressed OK and proceeded to do what I was trying to do. INTERLOCK mode has not seemed to have any bearing on what I have been trying to accomplish.
So, like I said, the program I want to run is selected. I can see it listed at the top left corner of the TP. But as soon as I hit START, first I often get a SYST-079 Startup Check Failed, which is a little odd because as far as I can tell, all of the startup checks have been disabled. But hitting RESET and issuing another START takes care of that. Once the START is issued, the program we used all last week appears on the pendant, replacing what I just selected and begins to run.
If background edit is an option on this old controller, we do not have it. I'm not sure I've ever done any background editing on any of our robots. There is no background logic or condition monitors or any other obvious reason for this robot to do this. I mean, we literally just bought this robot, refurbished, placed it in a new work cell, and ran our first order last week with no major issues. We had another job to run this week, so we wrote a new program, hit START, and it goes right back to the first program we put on it.
Now, this robot came from the same place we've bought most of our robots from, and I've never gotten one that had any signs of previous ownership (i.e. old programs, configurations, etc.) They always come wiped clean and ready to integrate into whatever application we choose. We've done power cycles on the machine with RESTORE SELECTED PROGRAM disabled - so I am forced to SELECT the program I want to run, but it continues to jump out of the selected program and back to the old one from last week. It is the weirdest thing... 
If you are using the Other selection method, what are you using to change your program? As i understand it, when you have the selection style set to other, it will run whatever program is listed in $shell_wrk.$cust_name, so if you want to change what program runs, you have to change this. We do this to run a main program then just use digital I/O to navigate our process flow after that. Try changing the name of the program to be launched by Other, see if that solves the problem.
Here are some options that we use to some degree.
1. Run a main program, then use digital I/O in the main loop to branch out to specific programs. This can be done via PLC to make things pretty user friendly. We have a UI with a list of part numbers and descriptions. When they select a part and hit run, it toggles the I/O to branch into that program.
2. Explicit Messaging. You are able to use this feature to send the name of a program directly to a String Register, then use background logic to set the system variable to the string. This is effectively the same as the other option, but cuts out the need to manage branching on the robot side.
3. Set up a "Run" program with nothing in it but a "Call" statement, then have the operators choose the program in the parameter of the Call statement and hit start. It will auto execute the initial program, which will then trigger the selected program. This is probably the closest you are going to get to selecting from the menu and running, without switching back to Local.
A cool thing would be to have a BG logic that would read the current open program from one system variable, then write it directly into the pre-set run program system variable. That way, you could open the program and hit the run button and it would do exactly that.
As for how it got there, it can be entered under Setup (i will have to find the proper path) but the same place where you set it to PNS/RSR/Other. It does not have to be set via System Variable.
Edit: Proper path looks like MENU -> SETUP -> PROG SELECT
If you go this route, some things to watch out for:
1. Stack overflow. Make sure that your sub called programs come to an end before returning to your main call program. By default, it should complete the subprogram, and then return to the main, there is no need to re-call the main at the end of each sub.
2. Put in a mechanism to pause the main when a change of program is needed, otherwise it will re-trigger the same sub over and over without giving you a chance to choose.
3. There may be a way (i am not sure) to have a pop-up occur on the TP which will prompt the user to select a program. I am not sure what all is available, and what is impossible. It is not something we have ever looked into since we put all macro scale decision making on the PLC, and only leave the more micro scale decisions to the robot.
4. To prevent the need to abort tasks and switch to Teach mode to change the program, it may be in your best interest to have an interface via some other inputs. If i were setting up a system to run like this, i might have a range of Digital I/O or flags which were labeled with each of the available program names, and then have a master program called by the UOP start which would check for a change in I/O status, and run a program based on this. It would be possible to use a Register to count parts down to a new program change, and a register or duplicate range of I/O to keep track of what the previous program was. Ideally, you would want to make it so that only one program could ever be selected at a time.
I hope you are able to get your system working in a way that satisfies everyone on your end!
[shadow=red,left]3. There may be a way (i am not sure) to have a pop-up occur on the TP which will prompt the user to select a program.[/shadow]
There is a way to do this. I think you have to have the Menu Utility option. An Operator Entry menu and/or List menu will do this. The Operator Entry menu can be configured to accept various types of data such as boolean, numeric, etc. The List menu can be configured to list up to 8 items or so that can be selected.
[shadow=red,left]3. There may be a way (i am not sure) to have a pop-up occur on the TP which will prompt the user to select a program.[/shadow]There is a way to do this. I think you have to have the Menu Utility option. An Operator Entry menu and/or List menu will do this. The Operator Entry menu can be configured to accept various types of data such as boolean, numeric, etc. The List menu can be configured to list up to 8 items or so that can be selected.
That is great information! I am not sure we have the Menu Utility option, but i may look into that for our new training cell!
