LV2009f2 vi corruption

[viSci]

Hello all,

I have a rather dire situation in which a top level vi that was being run from the project was corrupted. If I try to open it I get the dreaded error code 3 - could not load from panel.

I had been running the vi for several hours and then stopped it normally. I then tried to do a build and it failed. I was late to pick up my son so I did not read all of the details of the error message but rather as I do every night did a backup. This morning I find that the vi is corrupted, the backup now is corrupted and the last exe has been wiped out since the build failed. The vi looks ok from the file size so I have some hope that NI might have tool to analyze the problem and fix it. Does anyone have any comforting words of hope to share?

[viSci]

Just a little memo to all who responded (none actually) that I sent in my corrupted vi to an AE at NI and within 24 hours he got it to R&D where they were

able to repair the self inflicted damage. I would really like to know what kind of tools they are wielding. The big lesson learned is that the damage could have

been much worse and that was a big wake up call to get tortoiseSVN in place. Now I will do a daily revision of my source code and a backup of the SVN repository.

Thanks NI for your help and quick response.

[Yair]

I would really like to know what kind of tools they are wielding.

It's probably something as simple as a version of LabVIEW or a tool which doesn't do all the sanity checks and verifications, but just loads the VI and allows them to look at it regardless of the problems it may have. It's easy to build such a tool when you have the source code.

The big lesson learned is that the damage could have been much worse and that was a big wake up call to get tortoiseSVN in place. Now I will do a daily revision of my source code and a backup of the SVN repository.

Agreed, but that's only part of the lesson. Additional parts are (for instance):

• Backing up the repository itself to an off-site backup (using the "svnadmin hotcopy" command, if memory serves). For example, you can get a couple of USB drives and just bring them in to work on alternating days and run an automated script to backup and copy the files to the HD.
• Adding comments to your commits so that you know exactly when you changed what. It becomes very convenient, two years down the line, when you want to see what things were like before a specific change was made.

[viSci]

Just found out from NI R&D that the problem is repeatable and is caused by attempting the customize the digital numeric on a slider control. The vi will run once but thereafter will be corrupted.

A CAR has been filed.

[Yair]

... the problem ... is caused by attempting the customize the digital numeric on a slider control.

Doctor, it hurts when I do *this*.

Well, don't do *that*.