LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView crashes with access violation error at random times

Hello,

 

I am using a system which has been developed over the years by a lot of people, so the library is quite big. In short we are trying to run traverse motors and get pressure and temperature readings from probes. Other than that we have stationary pressure and temperature readings coming from the system. However to monitor certain parameters in real time, an online excel sheet is used using the data from the stationary systems. This excel sheet requires DDE links for all the sensors to be connected. These same readings are also fed to another VI where the values from the traverse also get concatenated.

 

The main VI works sometimes fro hours without crashing, and sometimes it crashes consecutively within space of 15 mins. I am not very sure of what to test so that I can start debugging.

LabView 16 and Windows 7 SP1. I have attached the log file generated after the crash. Please let me know if anyone has any suggestions or ideas?

0 Kudos
Message 1 of 4
(1,070 Views)

Sorry i had forgot to attach the crash window, here it is!

0 Kudos
Message 2 of 4
(1,036 Views)

Crashes. Welcome to LabVIEW.

 

On a more serious note, please learn how to take screenshots in Windows. The "Print Screen" button takes a bitmap of your desktop and places it in the clipboard. MSPaint (I actually prefer Paint.NET) can be used to select a portion of that and save it as PNG. It only needs about 2% of the space of your ridiculously large JPG included in the post.

Message 3 of 4
(1,006 Views)

You don't really provide much information here (the huge image is pretty much totally useless anyways, we all know how a LabVIEW crash dialog looks like and it conveys no useful information about the crash itself!)

 

Now you mention a lot of hardware you are using. Are any of these integrated in LabVIEW through Call Library Nodes calling into DLLs or .Net drivers? Or are they all communicating over standard VISA or LabVIEW TCP/IP resources? Especially if you have DLL interfaces, this is almost always the first culprit to search. Many start out integrating DLLs in LabVIEW and declare victory as soon as it doesn't (immediately) crash anymore. Nothing could be further from the truth! A DLL interface that doesn't crash, simply hasn't been exercised enough in most cases. It takes a lot of expertise to be able to claim with reasonable certainity that such an interface is properly written so that it in fact won't crash anymore.

 

Now you do mention DDE communication too and in absence of DLL drivers being used, this is indeed another  possible culprit, especially since some of the entries in the lvlog.txt file seem to indicate that LabVIEW was actually inside some of these DDE VIs at the time of the crash. However, some of these VIs while having standard names of the DDE Vis (DDE Srv Set Item.vi) seem to be private (and possibly modified) versions in your own project libraries. Without knowing why there have been made copies of these VIs and what was changed it's a good change that someone tried to be to smart for his own good and modified the standard LabVIEW provided VIs in a way that may be part of the problem. Also why does the next VI (Set Item value in DDE Server 2003-02-05_old.vi) use the name old in it? This might indicate that someone already tinkered with this VI somehow, possibly for crashing reasons, but then the old version was placed back in the code?

 

Unfortunately for you the DDE interface in LabVIEW is far beyond legacy status. NI stopped caring about this interface almost 20 years ago and simply left it as unsupported technology in the LabVIEW distribution for backwards compatibility but won't provide any support on it anymore. So if this crash is caused by something in the DDE VIs, it is more likely that they will remove the library in an upcoming LabVIEW version than provide any bugfixes.

Rolf Kalbermatter
My Blog
Message 4 of 4
(987 Views)