Hello. Hope all of you had a great holiday
I showed up for work today, to a very unpleasant surprise.
I have lost all my installation variables, and therefore I cannot run my program due to an “unfinished program”. I have only lost my variables. The rest of my installation file is as I left it the last Thursday.
Being optimistic, I decided to just reassign all of them with the exact name(I only have about 30). But it seems like somewhere the controller still has access to these variables a
nd will not let me reassign the same name. I have attached pictures from installation variables, the searching for the variable and features.
The specific one I am looking for here is “Free_drive_pos”, which is a pose I assign as “get_actual_tcp_pose()” and then go to the position during initialization. So, I know for sure that I am not using it in a subprogram or script.
I am having this issue with 9/30 of the variables I used to have in my variables file.
To get back up and running, could some of you suggest where I might find these variables or something? Or tell me how to find/delete old dependencies?
I downloaded the log/support file, went through all “.variables” files(on my own computer) but all of them are empty. I am kind of clueless by now.
Furthermore does any body have an idea of what happend? Or at least an idea of how to avoid it in there future ?
Last thing I did Thursday was to make a system backup. Restoring this did not help me at all though.
best regards Anders
I’m certainly not an expert, but there’s a couple things you could try.
First, reboot. I’m not sure how linux works, but windows blows if it’s been running a while.
Second, I’m assuming you don’t have a backup, otherwise you’d use it, but sometime people forget.
Third, see if you have the “20801.variables” file in the directory structure. This is the file that contains all the variables. Possibly a backup exists with that file?
Fourth, are there any local variables that may be using that name?
Thx for the reply.
Not sure if you read the bottom of my post(after the pictures) but I actually tried all of these. For once I was a good programmer and did a backup before Christmas, tried to restore from that but it didn’t work.
I did try rebooting and I checked ALL my “.variables” files, which included a lot of “default_x.variables” to see if it somehow was ended up there. All of them are empty.
My best guess is the backup I did, f***ed up somehow.
Strange thing is I have two machines, completely similar, which is completely fine…
Guess it is a problem for “future-me”
Have a nice evening!
The filename.variables file does not contain the declaration or instantiation of the variables. It only contains the values those variables held when the program was stopped or robot shut down. The declaration of the variables is within the INSTALLATION file itself (e.g. default.installation). This you can see under Installation->General->Variables… this is where they get declared.
That being said, I don’t have a clear explanation for why polyscope thinks these variables are undeclared (why they are yellow in the program tree). Usually restarting polyscope solves this problem. Sometimes you have to suppress the variable in the program tree and then go back to the installation tab and recreate them.
Thank you for the explantion of where the variables where declared. Good to know.
I tried restarting polyscope without any luck. Tried restoring backup without any luck.
I tried to suppress the variables in the program(what I tried showing with the picture of the program, as you can see the position is not used in the program any more), it is not declared within installation nor as a feature. The variable do not exist in the installation file nor the program, or at least the part of polyscope that I can acces.
My actual problem is that somehow, even though, the variable is not declared, I can not declare it once again as it is still referenced somewhere.
If this where only one variable, it would not be an issue but as it is more variables it start being time consuming changing the variable names(in my software but also all user guide documents).
As the costummer can not do programming, I am affraid that this will happen again when I am not around to fix it.
Is there any work around for this?
Furthermore, if this is a known problem for UR, I think it should be worth fixing?
It is just waisting valuable time, which I have to catch up somehow.
Any ways, happy new year when you reach that point
I have seen this problem before, but thought it had been fixed. What version of Polyscope are you using? Are you a URplus partner?
If you are ok sending me your program + installation file (and any subprogram files it calls/includes) I can take a look and see if I can sort it out. My email is email@example.com Also, let me know if you are using any URcaps in the system.
If every one else encounters this problem, here is the answer I recieved on email;
I did some digging around in our internal bug database and found what I believe is a similar problem. So this is a known bug and it is being worked on. For reference the bug is listed as TEC-693. I was able to fix the problem by editing your installation variables file (20801.variables) and adding a value for the missing variable. As an example : En_freedrive=False So if you wanted to fix this you would have to do this for each variable that was in a yellow state in the tree.
My understanding of the bug is that this seems to happen when you are copying files back and forth from an external computer via ftp or something like that. I think the issue is that Polyscope still has a pointer to the original installation file in it’s memory and when you copy a new file over and attempt to use it somehow (editing something in the program tree perhaps) polyscope will get confused and somehow delete the values for all the installation variables from the 20801.variables file which results in all the installation variables being invalid.
The key to fixing this is to NOT have your installation or program opened while editing the file (20801.variables). SO what I did was I created a new program (blank) within polyscope, THEN opened a different installation file (default), THEN I edited 20801.variables. Once the editing/copying is done then it is ok to open 20801.installation as well as the working program. This would be the technique for copying files back and forth from a development system too.
I think the best advice for you to move forward is to fix the file, establish working values for all the installation variables and then save a backup of the installation variables file (20801.variables.bak) in case this happens again in the future.
Below is a screenshot and example of how I initialized some of the installation variables that were previously not initialized.
Just a bit more clarity on how to avoid this problem. The issue is that you should not have your installation file or program open within Polyscope while you copy a modified installation and/or program to the robot from some external USB drive or via ftp. As an example, if your installation file is called my_installation.installation then open something like default.installation within Polyscope before you copy my_installation.installation on to the robots SD card.
We’ve had this problem with a multitude of robots in the field now. The instigating factor in most cases is that the robot was inadvertently disconnected from power instead of being powered down properly. Any work on making the management of these variables more robust would help reduce some of our support calls.
Yes, I can imagine that this is another possible cause of this problem. Thanks for the insight and I will pass it on to R&D.
As you are probably aware, the controller should never have AC power just removed without doing a proper shutdown of the controller (and thus Linux). If a system design cannot guarantee this then a UPS is what we would suggest.