LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

labview 2009 crash when importing LV 8.6.1 project

Hello all,

 

I just got the LabView 2009 DVDs this morning. The installation went fine; there was a small hiccup with activation but that worked ok an hour later.

 

However, I am having a pretty poor experience with it. I have been trying to open various parts of my (LabView 8.6.1) existing project, and in most cases LabView 2009 crashes. There is no dialog box or warning; it just vanishes. On restart, the crash recovery code does not launch. I've been able to load a few simpler pieces of code but have not yet isolated what kinds of structures are causing the problem. (If I had to guess, I would blame dynamically dispatched LabView classes, since none of the code I've been able to open successfully uses them.)

 

Has anyone else had this problem? 

 

I'm using LabView 2009 for Windows, 32 bit, version 9.0. 

 

Thanks,

 

Rob Calhoun 

  

0 Kudos
Message 1 of 8
(3,443 Views)

A bit more of a clue: some code containing a mathscript node did not compile, stating that the mathscript RT library was not licensed or installed. (Is this really necessary to use mathscript on a non-real time OS?). Installing that allowed that particular chunk of code to compile.

 

It is still tanking when I try to open larger pieces.

0 Kudos
Message 2 of 8
(3,434 Views)

Hi Rob,

 

If you just got your disks you probably have support with NI. I would give them a call at

 

800 433-3488

 

and tell them 2009 is crashing. You should be able to get someone to try opening your VIs (you can upload password protected zips  using NI ftp site).

 

If you can get a confirmation you may be the first person to report a bug in 2009*.

 

Ben

 

LabVIEW 2009 not the year. It much too lat for that.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 8
(3,431 Views)

I agree it is probably time to call NI. I have found a class that crashes LV repeatedly. It does use dynamic dispatching, but I was able to open another class that also uses dynamic dispatching successfully so it is not simply the dynamic dispatching that is causing the problem.

Message 4 of 8
(3,414 Views)

Hi,

Even I'm facing same problem,but here i'm not using Math RT.All code I've changed was totally gone.

 

when Next I try to open my code ,It asks for recovey..

 

And if I want to recover,I'm not able to save the recovered code..

 

so I preferred not to recover and rewrite the code

 

Vaishali

0 Kudos
Message 5 of 8
(3,254 Views)
Are you asking how you can cancel the recovery or are you just stating that this is what you are doing?
0 Kudos
Message 6 of 8
(3,225 Views)

I neglected to update this thread with the resolution of my problem. It was as follows:

 

We eventually isolated the issue to a very large enum. (1950 defined values and about 56,000 characters of associated character data.) In order to save a file on disk, the data structures must be serialized. I assume the process used is the same that is exposed in the Flatten To String G function. The serialized data format uses unsigned 16-bit integers as internal pointers, with the result that no single cluster or class can have type descriptor data longer than 64 kwords.

 

We knew we were fairly close to the limit but everything worked fine in LabView 8.6, so we had deferred addressing this. LabView 9 apparently made some changes in how data is flattened/unflattened (perhaps associated with versioning in classes) and it could no longer handle a class containing such a large enumerated type. (LabView 9 could load the enum by itself without problems; what it could not do was load the enum inside a complicated class.) Rather impolitely, LabView 2009 silently tanked on VI load rather than identifying the problematic structure. (This part is going to be addressed: NI employees see CAR #185348.) 

 

This issue was quite difficult to isolate because of the cross-linked nature of LabView libraries and classes. Although I knew a particular class induced the crash, loading any method of a class loads every method of the class, as well as any parent classes and subclasses and any VIs present in any library used by the class. This meant that isolating the problem to "class x" really only reduced the scope of the problem to one of about 450 VIs and controls. I will avoid derailing this post with a rant about the nightmarish dependency issues introduced with LabView libraries, but suffice it to say that libraries have caused me many more problems than they have solved.

 

In the end was necessary to strip everything out of the class so that LabView 2009 could read the class, then add things back in until it broke. This was slow but ultimately successful. (I should remind everyone to use a source code control system: it would be unthinkable to do this kind of slash and burn debugging without one. We use subversion.) I want to thank applications engineer Mark Eadie at NI for working on this problem with me.

 

In the end we refactored the single large enum into a composite structure. This change had to be made in LabView 8.6. Once that change was made, we were able to load the project in LV 2009.

 

-Rob 

Message 7 of 8
(3,209 Views)

Actually it appears that the large enum crash is resolved in LV2009 f2: see ID 185348

 

 

http://digital.ni.com/public.nsf/allkb/C3F88F3596A164AD86257647006FB022

 

 

Message 8 of 8
(3,202 Views)