Unable to recover project after typedef crash

[s.h._tech]

Hello everyone,

I once again have a problem with Strict-Typedefs. This relates directly to my problem in this question. Usually when I need changes in typedefs I save the whole project and make a copy of the entire folder and then close the typedef. Sometimes LV crashes and I am able to recover the project with the changes of the typedef. (Sometimes some variable of enums and unbundle-by-name are changed -> also annoying). Overall a very annoying and time consuming situation but I have learned to live with it.

Now I am in the situation that the project crashes on startup and I am unable to open the project or VIs with the typedef in it. Does anyone else experienced this behavior? Are there certain steps I can take to 'force' changing of variables. (LV Version 17).

Note: I hope it is a user error. Usually changing/ adding/ removing variables should not affect a stable programming language or its IDE.

[GerdW]

Hi sh,

---

@s.h._tech wrote:

Now I am in the situation that the project crashes on startup and I am unable to open the project or VIs with the typedef in it.

---

First suggestion: check out an older revision of your sources from your SCC system to start over again.

2nd suggestion: delete all/most CTL files in your project (after creating a backup!), then load the project. Accept the missing typedefinitions to be able to load the project again. Then include the typedefs one after the other back into the project.

3rd suggestion: don't change (strict) typedef so often…

[s.h._tech]

---

I got the project running again (with an older version). I tried following workarounds:

• Removing all (!) *.ctl and adding only the one I want to change -> crash
• Only change the VI (without the project in memory) and then open a VI with the ctl inside -> crash
• Replace the cluster in the ctl with the Replace function of the 'RightClick Window' -> crash
• Nesting the cluster in another cluster -> crash

My guess is that LV can not refactor variables at a certain point. Either because of the project size or the amount the ctl is called. Our NI-Rep also replied to that problem with: "Huh, that should not happen". He gave the dumpreports to the developers, but I do not have high hopes that this problem will be resolved.

Since I am out of ideas I only can implement the most inelegant and convoluted solution I can think of: Adding new typefs when a new variable is needed.

---

@GerdW wrote:

3rd suggestion: don't change (strict) typedef so often…

---

I would like to know the structure of the finished application before I start programming too.

[billko]

I've never seen this problem before, but perhaps it's because I don't work on humongous projects.  I do exactly what was described in the solution for the topic you referred to.

Additionally, if it is an enum I am modifying, I always move the targeted item to the bottom of the list, apply, save it, save and close the project, re-open the project (and the typedef'd enum), remove the item, then apply, save and close the project, then open it and proceed.  It seems that LV is happiest when you don't tell it to try to rearrange the enum at the same time you are deleting an item.

[FireFist-Redhawk]

---

@s.h._tech wrote:

---

I got the project running again (with an older version). I tried following workarounds:

• Removing all (!) *.ctl and adding only the one I want to change -> crash
• Only change the VI (without the project in memory) and then open a VI with the ctl inside -> crash
• Replace the cluster in the ctl with the Replace function of the 'RightClick Window' -> crash
• Nesting the cluster in another cluster -> crash

Did you try just opening the troublesome ctl by itself, straight from LV home screen? No .vi's, no .lvproj's, just the ctl.

[s.h._tech]

I do not think humongous is the right word. 11 parallel threads (with queues) which share a common datastructure (Cluster with boolean statusbits). Every thread has its own class with the necessary variables. Sometimes this threads need to be synchronized using rendevous and notifiers. The generated data is manipulated and handled via a self written program (Java) and fed back to LV in order to change the testing conditions. I tried to reduce LVs work only to measure and synchronize.

I tried another dirty trick:

I copied the ctl and edited it (Input.ctl -> Input_NEW.ctl). Then I added the new ctl to the same class-control and after I dropped it LV crashed. Adding a new cluster to the class-control is not a problem, only changing and adding a copy of an already existing one. Deleting the control also crashes LV. I think LV got me boxed in, since I can not change the ctl and also not remove it.

[s.h._tech]

---

@FireFist-Redhawk wrote:

---

Did you try just opening the troublesome ctl by itself, straight from LV home screen? No .vi's, no .lvproj's, just the ctl.

---

Yes. Completely closed LV and only started the control. No crashes. Only when opened in VIs that contain it

[FireFist-Redhawk]

I am just spit balling to try to find you a less crappy solution than your current one (aka no idea what these will do):

1. Open the ctl by itself, modify, save, close, open the project.

2. If the strictness of the type def is contributing to the issue, make the changes to the type def but save as a non-strict, then go back and change from non-strict to strict and save again.

[s.h._tech]

I currently 

---

@FireFist-Redhawk wrote:

1. Open the ctl by itself, modify, save, close, open the project.

---

Also results in  a crash

---

@FireFist-Redhawk wrote:

2. If the strictness of the type def is contributing to the issue, make the changes to the type def but save as a non-strict, then go back and change from non-strict to strict and save again.

---

I currently trying something similar. Adding a Typedef with similar variables and disconnecting the strict-typedefs (not deleting). So far no crashes, but some unbundle-by-name changed their values again. I have to manually disconnect the old and connect the elements in every VI it is needed. If this works I will try to delete the old strict-typedef (when no dependencies are left). If it still crashes I will leave the old strict-typedef in the project and continue working. The only problem is that I would distrust the programs functionality when I know that there may unstable elements in it.

[billko]

---

@s.h._tech wrote:

I currently 

---

@FireFist-Redhawk wrote:

1. Open the ctl by itself, modify, save, close, open the project.

---

Also results in  a crash

---

@FireFist-Redhawk wrote:

2. If the strictness of the type def is contributing to the issue, make the changes to the type def but save as a non-strict, then go back and change from non-strict to strict and save again.

---

I currently trying something similar. Adding a Typedef with similar variables and disconnecting the strict-typedefs (not deleting). So far no crashes, but some unbundle-by-name changed their values again. I have to manually disconnect the old and connect the elements in every VI it is needed. If this works I will try to delete the old strict-typedef (when no dependencies are left). If it still crashes I will leave the old strict-typedef in the project and continue working. The only problem is that I would distrust the programs functionality when I know that there may unstable elements in it.

---

I'm sorry it seems to be coming down to that.  That's totally ugly.  😞