Current Program ID Variable and how/when it gets that ID

Hello all,

I believe the answer is that the Current Program ID is generated when the program is loaded into a controller. Just looking to use the variable for some Home routine tracking. I initially made my Home program in Roboguide with an older backup of my real robot and was given ID: 2246 for my program I want to track. When I went to my real robot and dumped in the Home program I realized that the ID for the job is now 2259.

So it seems it generates that number per controller...I also tried restarting the robot to see if that number would be regenerated on a restart and it kept the same.

The end goal I'm trying to find here is: Will this number of the program stay the same for the life of the controller...Last thing I want is for the Cur Prog ID of that program to change, then the robot doesn't realize it ran the program and will not run the correct home path.

Pretty far out there topic and I'm suspecting no one here will know the answer as per usual with some of my crazy questions on here

Thank you for any help that may be provided!

Tom

True, but then why not just set a flag to be ON?, etc.

I'm trying to make my programming overly complicated for no good reason other than taking control from the user

But in all seriousness, since this is for a Robot Home program, I want to avoid someone skipping over setting a Flag to be On or a Register being set, etc. I already have the majority of my home program to be able to detect where the robot is and home from there without the user needing to be involved. Sure...I could just train the end user "nuh uh uh, don't skip over this line, it's very important", but I've had too many times those that don't listen or think they know the robot programming better. Trying to avoid that stuff/warranty call/going back out in the field to patch the code with something dummy proof!

And to clarify why I can't user robot location with this, I need to distinguish between a tack welding program and the main welding routine, which use different paths to get in and out due to interferences from fixturing at certain stages.

Quote from HawkME

In that situation I've always used a combination of location and a register.

I believe there is a variable with the current program name. Maybe that would work better for you.

Yeah I saw Current Program Name as well, but problem with that is I'd have to see if Current Program Name Variable = SR[x], where SR[x] = WELD_TACK. That works as well, but I'd like to have control over that String Register, so that it can ONLY have WELD_TACK written into it. You cannot do that in TP Programming unless you CALL a routine with an Argument Register set to 'WELD_TACK' (i.e. I cannot set SR[x]='string'). I couldn't find anywhere out of the User's hands to make that happen. Not in BG Logic either because you can't CALL in BG Logic and you can't send Argument Registers with RUN.

I'll keep monitoring the Cur Prog ID variable and see if my program ID's change at any point. We still have a lot of running to do with this machine, so if the ID changes I should see it and hopefully find out how/when it changed.

And of course I honestly can see that I'm probably just going waaaaaayy overboard here...haha. I have too much fun experimenting with new ideas to try and make a more solid machine for the end user.

EDIT: I could maybe make Location & Register work...We are shifting the UF around a bit depending on what combination of stuff we are welding together...I could maybe make that work if nothing else.

Quote from EnergyAddict

It appears the ID is a number that is determined when the program is added to the controller.

I'm not an expert, but I tested in RG, and made some observations:

I added/Ran Several programs Test1.TP was 1575, Test2.TP was 1576, TEST3.TP was 1577 and so on. I then deleted Test2.TP and added a RETEST2.TP and RETEST2 took over the 1576 ID, despite TEST3.TP still being on the controller, It's like the new program filled in the unused ID left behind by Test2.TP.

Changing the name of an existing Program also changed its ID.

Basically, I don't think your program is 2259th program on your controller, but it's something similar to that, and as long as you don't delete or change the name of the program, the ID shouldn't change.

This seems like it could pose an issue if your customer ever does a file load in the future.

I'm surprised the ID isn't part of the program header when an LS file is taken.

Display More

That's better testing than what I had tried. Hmm...yeah it is a bit concerning. I will probably come up with something else. They have no reason to ever change anything in this machine, in fact it's best they never do. There's a lot happening with KAREL programs and background jobs. It's stupid, but that's what you get when the sales guy says "Of course we can do that! *pulls necktie*". But like you said, if they ever do a file load it won't do me any good.

Well I have enough other examples here to work something else up. Thanks for the info EnergyAddict. I'm sure that'll come in handy for others than just me in the future!