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.
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!
Hi,
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.
Hello.
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
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 bba@universal-robots.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;
"Hi Anders,
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.
Hi,
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.
OK, are you copying an installation file on to the robot with the same name as the one that is loaded into polyscope memory? if you are this will not work and there was a workaround mentioned.
Yes that was the case. I’ve worked it around as previously mentioned: when copying program/installation files from PC to PolyScope via FileZilla I make sure that the program/installation file that I’m copying isn’t open at that moment. As of now, I’ve not encountered it agian. Thanks!
I’ve got something to add to this that might be useful.
We run our own daemon on the robots that store information in a JSON file. This was a way to work around the issues of variables being cleared on power loss.
Or so we thought. Recently our own JSON file was cleared on a power loss. I’m thinking this issue could be related to the Debian 8.9 / single board computer instead of polyscope.
Alright similar to the thread above I lost all the installation variables on the UR this morning when it was turned on, I have the *.variables backed up and will transfer it to the robot.
Polyscope version is 5.11 … , it’s been operating completely fine until now (no FTP, complete standalone operation) “so if it ain’t broke don’t fix it” and i haven’t had a reason to move it to 5.13.
Has this issue been resolved with the most recent version of Polyscope? Thanks in advance for the help!
** edit **
Leaving this here for anyone who runs into this issue in the future, hopefully this is resolved in the newer versions of Polyscope.
Risk Mitigation: Always take backups of *.urp, *.variables, and *.installation files. Don’t use installation variables for long term messages, counts, or master reference data (e.g. if you plan to keep a running count of cycles or store reference measurements) store these in a log message or pull/push from external source. I got lucky that my installation variables are only tracking steps within the program (ability to pick up where you last left off) if they pause or stop.
Issue: Remote program would not play, I checked the program and several assignment nodes were yellow w/ variables pulled from installation, I checked installation variables and they were all missing.
Cause: Unknown, operator went through normal power up cycle and program was not running (there was no popup displayed for incomplete program or missing variables). Note: I have an older UR running 5.9 with way more installation variables + more cycle time and NO issue with loss of installation variables.
Resolution: Loaded different program w/ different installation and used USB to replace the empty *.variables file with the backup variable file. Open the program back up and all the assignment nodes should be corrected and the installation variables all present in the installation tab.
