LabVIEW Corrupt from Shutdown?

[adekruif]

Several months ago I had an issue with LabVIEW that I though I had resolved, but another problem showed up today. 

I am using LabVIEW 2014 that is installed on a cDAQ-9139 chassis. Everything was working fine, I collected the data I needed at one location, and then shut down the cDAQ through Windows. I get to the next location to take data and when I powered up the cDAQ, I couldn't access my VI Block diagram. The VI that I was using prior to shutdown, the block diagram is now blank. The front panel shows up, but that's it. The several SUB Vi's that I have in the top level VI open perfectly fine, the front panel and block diagram both open. If I move the top level VI to my regular development computer,the block diagram and all my code is there. 

I thought that LabVIEW 2014 must have an issue so I downloaded 2017 and it had the same behavior on the cDAQ. At this point I decided that something in the top level VI must have gotten corrupted somehow. Not sure how since I shut down everything properly. 

Fast forward to today, I am using the cDAQ again, and I am working with a different LabVIEW project (A rather large project that was developed by a contractor). I can open the project and VI's in LabVIEW, but it takes 10-20 minutes per open operation. Once the VI does finally open I can run the VI. I don't know if the VI runs as it was intended to as it's a large project and I haven't dug into it too deep. I should also note that we have an exe installed from the contractor and when I run the exe, most of the time it doesn't fully load the exe. Every so often the executable runs as it should, no idea what changes. 

At this point I am thinking that something in LabVIEW is corrupt, but I have no idea what it would be or how it would have gotten corrupted. I would try repairing LabVIEw 2014 to see if that is where the issue is, but the cDAQ came loaded with LabVIEW 2014 on it when we got it from the contractor. I'm sure I can get some help through NI to repair it, but I thought I might ask here first. 

Does anyone have any experience with something like this? Is there anything I can check to see if it got corrupted somehow? I'm all out of ideas at this point. 

[JÞB]

Without looking at it I can only guess.

But, my guesses are usually pretty amazing. 

The first thing I would ask is what licenses are on the target?  It sounds like you may have a different flavor of the IDE on the cDAQ.  Base, Full, Pro, what toolkits and modules.?  License manager screenshots can help if you don't know what I'm talking about.

Then I would suspect that someone cross linked a vi in the exes support directory.  That would be bad and corrupt a whole lots stuff requiring lengthy searches to find components from odd places.  (Sounds familiar right?)  That would require reinstallation of the exe.  I hope an installer was delivered.

Also, I would look at the source code and see if there are conflicting MAX configurations between the exe and the system as configured.  (And fix any error handling that is not being done right)

And yes, I charge to look

[adekruif]

Jeff, thanks for your reply.

For the licensing, I had a new license file installed on the cDAQ to see if that was causing the issue. The 2014 license on the target is a professional license with the following tool kits:

- Application Builder

- Database Connectivity Toolkit

- Report generation Toolkit for Microsoft Office

LabVIEW 2015 and 2017 and are licensed on this machine, both professional.

As far as cross linking a VI in the exe's support directory, the source code hasn't been touched since we received the cDAQ, we have only run the exe. We have had to change the MAX configuration as there are times when we have to reset the MAX configuration to get the program to working properly. Maybe this caused something to get corrupted?

[JÞB]

I absolutely shudder when I hear

The source code hasn't been touched

Since you know that as an undisputed fact..  re install the source code from the SCC repository you are probably not using .  Would you like to make a bet? 

[adekruif]

I am the only one who has access to the target as it resides in my office. It is never on the network so no one can remotely get into it, so I can confidently say that the source code hasn't been touched. I keep a copy of the source code on my development machine so I can look at the code as required. 

I tried to open MAX yesterday on the target and it wouldn't even open, so I am uninstalling and reinstalling that to see if that is causing the problem. If that doesn't resolve it, I will reinstall the source code and go from there.

[JÞB]

With MAX failing to open resetting the MAX database is reasonable.   It's easy to accidentally move a dependant file and or forget to close it when updating stuff on the system.

Something in your source code changed...and likely in a dependantcy also used by a MAX component.   Worse, from your discription the error source was likely between keyboard and chair.  It happens.:D

[adekruif]

Hopefully it is just a classic PICNIC error. I will update when I get more info. 

[JÞB]

---

@adekruif wrote:

Hopefully it is just a classic PICNIC error. I will update when I get more info. 

---

I had a contractor once move vilib, intentionally,   because he didn't think it should install at the default location.   

This will be easy to fix by comparison.