LabVIEW load error code 1: LabVIEW load error code %ld: %p

[Jiafan]

Hi,

I also meet such a error when I editting my simple VI. But I am using windows, not OS. Is it any solution to recover the file? It took me 3 days to modify the latest function in this vi.

[Shazlan]

Hi Jiafan,

I talked to several people here and came to a conclusion that I had to rewrite my program again. And that's what I did 😞 

Shazlan

[MoReese]

---

@Shazlan wrote:

Hi Neil,

I just had the same problem yesterday to one of my VI's and I am using Windows. So, I don't think the error is OS specific. Now, the file is corrupted and I got the LabVIEW Load Error 1 (see attached) every time I try to open the file. 

This happens when I was troubleshooting my code for memory leaks. I found the bugger, fixed it but before I could save it, I got the full memory error dialog. I clicked OK and stubbornly tried to resave the file. The memory is full pops-up again but this time, LabVIEW crashed after I clicked OK... and now, the VI is already corrupted. Is there a way to save this? Unlike Neil's case, this VI is one of my major subVI's in my program.

Shazlan

---

When I get error code 1, it is usually related to a file path.  Typically, LV cannot find/access/recognize the file you are trying to access.

[Jiafan]

Hi Shazlan,

Yes. I should rewrite the program. But it is really stupid without solution to fix the error.

[MoReese]

---

@Jiafan wrote:

Hi Shazlan,

Yes. I should rewrite the program. But it is really stupid without solution to fix the error.

---

  
Not at all.  The most important decision you can make is determining FIRST which archetecture to use.  This may be beside the point now.  I don't know if you are doing upkeep with legacy code or not, but redesigning with the correct archeteture would be a good idea.  If the problem persists, you can deal with it then, but sometimes these problems take care of themselves doing it the right way.

[nbf]

Increasingly I only use LabView only when abolutely necessary. All the bells and whistles in the world are not a replacement for robust behavior. If you have any procedural programming background, or desire to acquire it, most of the functionality of LabView exists in more robust applications such as Matlab, Mathematica, Image J, etc. There is also good old C++ programming. When an application crashes and with it destroys your work, it might be a good idea to invest your time in other platforms.

Neil

[johnsold]

I am sorry that you have gotten so frustrated.

I have been programming in LabVIEW almost exclusively on the Mac since version 1.2 and have not experienced the problems you seem to be having.  More likely the problem is something about the way you are writing the programs.

1. Using Preview to grab screenshots allows them to be saved as .png.  The more recent versions use .png as default.

2. Profile >> Show Buffer Allocations shows at least six 2D array allocations (IP QL to charge - bak.vi).  I have not looked closely at your code, but I suspect that the number can be reduced.

3. Corrupted VIs, regardless of the OS, are usually best discarded. Go back to the last saved backup which was not corrupted and start from there.

4. Saving large amounts of data in a VI seems to be one of the ways to increase the probability of corruption.  Since you are reading data from files, there seems to be no need to have large amounts in the VI.

5. You have overlapping objects on the front panel.  Sometimes that can cause problems such as insane objects or redraw issues.  It certainly tends to slow things down a bit.

6. The Read from Spreadsheet File.vi will transpose the data for you. Wire a True constant to the "transpose (no:F) input.  That eliminates one buffer allocation.

7. Are your data files just 550 X 1600 arrays of DBL?  I created an array of that size and saved it with the Write to Spreadsheet File.vi and get a file of 5.3 MB.  When I run your VI, the IP QL ...vi uses 45 MB.

8. The revised version attached has only three 2D array allocations (compared to 6 in the original). It occupies 35 MB rather than 45 MB and executes in about half the time ( 147 ms and 367 ms).

Lynn

[Shazlan]

Hi,

I have to admit though, many comments here are right on the dot - VI corruption is mainly due poor programming. In my case, I was trying to do a quick "add-on feature" on a POC... a fatal move. Furthermore, since it is a POC, I didn't make any backup huhuhu... In a proper project, however, when proper architecture is adopted, I rarely came across such incident - I started using LabVIEW since LabVIEW 6 (2003).

Having said that, I think NI should still look into 'protecting' the VI's from being corrupted, regardless what the causes are. 

Shazlan

[nbf]

Hi Lynn,

  Thank you for the improved VI.

You are right that large amounts of data in the front end seem to correlate with file corruptions. I'm not an experienced VI programmer; but I think the worst that should happen when someone like me writes a VI is that it runs slow or it crashes. A program should not self-destruct because it is poorly written.

Neil