C++ Runtime Error.

[doogerk]

I am getting said runtime error after about 15 minutes of having my vi open. This error occurs whether I am simulating the vi or editing it. Originally, I had no such problems, but after many modifications and additions, I encountered this problem. The program operates normally, but after 15 minutes, i hear my HDD start to go crazy and then within a minute everything is crawling. It takes 15 minutes just to close all the programs and open windows. I originally thought it might be a bad reference, but the problem also occured when I hadn't been simulating, and I couldn't find any bad references. This particular vi is nearly impossible to debug because it is a vi that was included with the DAQ from Omega that I purchased. I made some modifications, but nothing to in depth (mainly isolating individual columns in an array and saving them to seperate files). The original vi is quite large, with many sub vi's, but again this problem happened after making changes to the parent vi and can occur when not in simulation mode. I have already tried reinstalling labview. I am hoping this is a common occurrence that can be narrowed down to make it easier to debug. Any help is appreciated. 

[smercurio_fc]

What do you mean by "simulating the VI"? Are you referring to using the Simulation Toolkit? You mentioned that this started happening after you made your modifications, so clearly the problem stems from that. You also mentioned that you were isolating individual columns in an array and saving them to separate files. You may want to check this code to see that you're not continuously increasing the size of the array or have an accidental run-away condition such as appending the previous contents of a file to itself.

That said, the "C++ Runtime Error" implies the error is coming from some DLL that you have in your code. This is probably from the DAQ DLL from Omega. 

Message Edited by smercurio_fc on 09-19-2008 05:09 PM

[doogerk]

When I say simulate, I mean run. The array does continuously get larger as data is collected, I just continuously append to the corresponding excel files. It seems to work just fine. It doesn't seem like the program itself is the culprit, rather, the file associations, as you said, the dll. Especially since it happens even when the program is not running. I am trying to remove some unneccesary parts of the vi, now. I originally added digital IO controls and Analog outs that I am not using, to the vi, so I will remove these and see if that helps. These were originally in seperate vi's and I combined them to form an all inclusive program. I am not using them, and the issue occured somewhat after I added them, so hopefully its that simple. Also, speaking of excel files, the vi has a scan rate minimum of 1 second, so that gives me 65536 seconds (18hrs) before and excel file is filled, I need approximately 3 months or more. I can modify my program to only save 1 sample out of every 100 which will give me sufficient space, but that is going to be a little bit of a pain. What happens when the excel file is full? If it just starts a new file with (2) appended to the name, that would be perfect. If it just continuously overwrites the last entry or outputs an error, then I have some modifying to do.

[smercurio_fc]

I found these two statements quite interesting:

---

doogerk wrote:
The array does continuously get larger as data is collected, I just continuously append to the corresponding excel files.

Especially since it happens even when the program is not running.

---

Without knowing anything about the DLL that you're using I can only guess that it's simply a data size limitation.

I cannot answer your questions about the Excel file because I don't know what DLL you're using, so I know nothing about its functionality. You can always simply save the files as tab-delimited text files using LabVIEW's built-in Write to Spreadsheet File (which actually produces a text file, not an Excel file).

[doogerk]

Yes. When I am not running the program, just editing it (block diagram, and front panel), I still get the error, I just need to have the project open. Also, I am using the write to spreadsheet file to save the data, with the append to file set to true. I forgot that the spreadsheet file is text, because I have it default to open with excel, therefore is suppose it can be as long as I want. I will just have to split the file up before I open it in excel.

[aartjan]

I, too, have an C++ runtime error, see attachment.

I have run into this error in several pieces of code and it is produced when running the code. At this point I don't know whether this code will build or whether the executable will also run into the error. I consider this an illigal error because it crashes the runtime and Labview itself, too. It is a bug in LV 8.6 runtime.

[doogerk]

I discovered that when this error occurs, my computer is running out of ram and it is starting to create a paging file for ram. This will slow things down. I added ram, now at 2GB, and the problem takes 2 days instead of 15 minutes to occur. So I am on the right track, but not completely home free.

[smercurio_fc]

---

aartjan wrote:

It is a bug in LV 8.6 runtime.

---

Has this been confirmed by NI, or is it your conclusion? Do you have a CAR?

[smercurio_fc]

---

doogerk wrote:
I discovered that when this error occurs, my computer is running out of ram and it is starting to create a paging file for ram. This will slow things down. I added ram, now at 2GB, and the problem takes 2 days instead of 15 minutes to occur. So I am on the right track, but not completely home free.

---

This indicates you have a memory leak in your code. 

[aartjan]

---

smercurio_fc wrote:

---

aartjan wrote:

It is a bug in LV 8.6 runtime.

---

Has this been confirmed by NI, or is it your conclusion? Do you have a CAR?

---

I added this post in the monthly buglist, so a CAR should be made soon. It is my own conclusion it is a bug, but probably not the runtime but rather Labview.exe

My error definetly is not a memory leak, so I probably should have created a new thread.

BTW. I have been able to make a fine running executable of the code that yielded the C++ runtime error.

Message Edited by aartjan on 10-21-2008 05:03 PM