Labview crahes on update enum typedef

[ad_dekkers]

I have an application with moe then 2000 vi's, when i want to update an enum typedef labview crashes!

A work around is: open only the enum typedef, change and save it and after that open the big application.

[Grampa_of_Oliva_n_Eden]

I have an application with moe then 2000 vi's, when i want to update an enum typedef labview crashes!

A work around is: open only the enum typedef, change and save it and after that open the big application.

LV 8.2?

Ben

[Jim Kring]

I have an application with moe then 2000 vi's, when i want to update an enum typedef labview crashes!

It would be helpful to the process if you are able to post an example that demonstrates the bug so that it may be reproduced. Otherwise, it's a needle in a haystack and probably will never be fixed.

[gleichman]

I have an application with moe then 2000 vi's, when i want to update an enum typedef labview crashes!

A work around is: open only the enum typedef, change and save it and after that open the big application.

I've had a similar problem with Type Defs embedded within Type Defs (LV 8.2). My solution is to open all related Type Defs and then make my changes. If I follow this procedure, LabVIEW does not crash.

[i2dx]

I mentioned this behaviour some time ago here

... which reminds me on asking, what happend to my input to NI ...

[Tomi Maila]

I have an application with moe then 2000 vi's, when i want to update an enum typedef labview crashes!

Try to do the following.

1. Make a backup of your project
   
2. Remove half of the VIs and check if your project still crashes
   
3. If your project still crashes, make a new backup of the modified project and return to point 2.
   
4. If your project doesn't crash, return to previous backup and remove other half of the VIs.
   

Go on the above cycle until you end up with absolute minimum number of files that still can generate the crash. You can still try to strip the project up a little bit further by removing stuff from the block diagrams of the remaining VIs. Then post that stripped up project to here and submit a bug report to NI with that stripped up project as an attachment.

[i2dx]

Try to do the following.

1. Make a backup of your project
   
2. Remove half of the VIs and check if your project still crashes
   
3. If your project still crashes, make a new backup of the modified project and return to point 2.
   
4. If your project doesn't crash, return to previous backup and remove other half of the VIs.
   

Go on the above cycle until you end up with absolute minimum number of files that still can generate the crash. You can still try to strip the project up a little bit further by removing stuff from the block diagrams of the remaining VIs. Then post that stripped up project to here and submit a bug report to NI with that stripped up project as an attachment.

the project will crash, independent of the number of VIs. I reproduced this bug with 4 VIs. IMHO and as far as I tracked that down, there is a bug in the updating mechanism, which updates all VIs after the edit, when you confirm the "replace ?" - dialog. This bug seems only to concern CONSTANTS, and does not occur if you use only one instance of that typedef in one VI

The service Request Nr. is 396436 (Nov 23. 2006) - as I mentioned above, I forgot to care about that and could not find any responses about this topic. Maybe this one needs a warm up and a CAR# ?

[Donald]

Hello Ad,

For me following approach works (on a fast PC).

Load the main VI or a Vi Tree that contains your application's modules.

If this fails (labview crashing during loading of VIs) -> try a mass compile of source code directory, and reload again

Force a recompile all. (Shift + run arrow) BEFORE edittting the type defs.

After the recompilation of everything, depending of your problem- it is possible to edit without crashing.

Save all VIs or better (or if you use SCC) save all the VIs you've been editting.

Good luck,

Donald

[Aristos Queue]

It would be helpful to the process if you are able to post an example that demonstrates the bug so that it may be reproduced. Otherwise, it's a needle in a haystack and probably will never be fixed.

If you can't reduce the size of the application, AND you don't mind sharing the app with NI, please go ahead and file a bug report with NI tech support using all 2000+ VIs. We will investigate a crash like this even on a giant hierarchy. Somehow a rumor got started that we won't do investigations of deep VI hierarchies, so folks have been avoiding submitting them unless they can get the bug to reproduce under a smaller hierarchy. While we certainly appreciate the leg work of you doing the reduction, we have been lately encouraging people to go ahead and submit the bug. Sometimes -- particularly for a bug like a typedef update -- it is a matter of moments to identify the problem VI when a debugger is connected to LV at the time of the crash.

[ad_dekkers]

the project will crash, independent of the number of VIs. I reproduced this bug with 4 VIs. IMHO and as far as I tracked that down, there is a bug in the updating mechanism, which updates all VIs after the edit, when you confirm the "replace ?" - dialog. This bug seems only to concern CONSTANTS, and does not occur if you use only one instance of that typedef in one VI

The service Request Nr. is 396436 (Nov 23. 2006) - as I mentioned above, I forgot to care about that and could not find any responses about this topic. Maybe this one needs a warm up and a CAR# ?

Can you post this 4 vi's?

For me following approach works (on a fast PC).

Load the main VI or a Vi Tree that contains your application's modules.

If this fails (labview crashing during loading of VIs) -> try a mass compile of source code directory, and reload again

Force a recompile all. (Shift + run arrow) BEFORE edittting the type defs.

After the recompilation of everything, depending of your problem- it is possible to edit without crashing.

Save all VIs or better (or if you use SCC) save all the VIs you've been editting.

Mass compiling doesn't help!

[snooper]

I am experiencing the similair since LabVIEW 6i.

In my opinion this is not VI or project related, it looks more like a memoryheap-problem.The problems occurs in the following situations:

1. If you create a strict. def from a enum and then put this into an array which is also an enum, then dray the constant out of the array and in 10% of the situations LabVIEW crashes (LV 8.0 or lower).

2. If you have a lot of VI's (indeed above 1000, thus large projects) and then start changing a strict def whithin another strict def. LabVIEW crashes somewhere during the update of the VI's. The solutions indeed is to change the stricttype def with no other VI's open. This mostly occurs when the typedef is a big cluster with other clusters inside.

3. Can someone at NI speed up the update process. Try placing a few hundred copies of a simple strict type def enum on a front panel and then change the enum values. A good moment for a lunch break

It is annoying, but I learned to life with it. (It helps if your computer restart LabVIEW fast)

Arnoud de Kuijper

T&M Solutions BV

[Aristos Queue]

QUOTE(ad_dekkers @ Jan 28 2007, 11:35 AM)

I have an application with moe then 2000 vi's, when i want to update an enum typedef labview crashes!

A work around is: open only the enum typedef, change and save it and after that open the big application.

Please contact NI tech support and file a bug report. If you don't mind sharing the entire VI hierarchy. We do investigate crashes on these large hierarchies when customers are willing to share their VIs.

What version of LV?

[TG]

Snooper I totally agree with your observation

" ...and then start changing a strict def whithin another strict def. LabVIEW crashes somewhere during the update of the VI's. The solutions indeed is to change the stricttype def with no other VI's open. This mostly occurs when the typedef is a big cluster with other clusters inside."

That is the closest (in my failing memory) as one could get to the conditions that cause the crash. Ive had many (crashes) but my LV starts fast and Im not an analyist so I don't have the time to investigate myself/..

I think this could be implemented with as few as 10 VI"S

Im sure NI is already on top of this one. IF not they should be.

We paid em