Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

.vi loaded with errors on the target and was closed

Hi all

 

I have been suffering heaviliy from this bug in LabVIEW 2014. Over the last 2 days i have migrated my code to LabVIEW 2015 and the issue seems to have been resolved!

 

Message 41 of 81
(4,197 Views)

Excellent news, please keep us updated if it comes back!

0 Kudos
Message 42 of 81
(4,191 Views)

I had this issue too. And after much trouble I found that 'Tools -> Advanced -> Clear Compiled Object Cache ..." fixed the problem.

Message 43 of 81
(4,137 Views)

I had this error which popped up from code that had been working for some time.  It started after either, 1) recreating one of my type-def's, or 2) generating an llb.

 

I finally fixed it by changing the TypeDefs which had been modified to strict-type and then re-running.  The error just went away.

0 Kudos
Message 44 of 81
(3,826 Views)

 

C:\Users\<username>\Documents\LabVIEW Data\VIObjCache\13.0.0r0\objFileDB.vidb


Many thanks. I had experienced strange deployement issues recently. And I couldn't understand why

Deleting thar .vidb file solved the deployement issue

 

As for NI, here is a quick description of NY system:

LabVIEW 2015, 32 bits

cRIO 9030

Using a code where an lvlib contains messages (classes) sent from a client over tcp to the crio.

 

Each time I do add a value to a strict typedef ed enums used by one of the lop level message class, I do experience deployement issues. The problem is still happening with recent version of LabVIEW, and I didn't use any .llb

 

Thanks gsussman for sharing your workaround. it truly made my day


0 Kudos
Message 45 of 81
(3,764 Views)

So I have once again been plagued by this issue, however the solution of clearing the compiled object cache has not provided a "one and done" fix to the deployment issue.

 

We have a large project (100+ classes) with some classes utilized on both the Windows and RT systems.

What we have found is that if any of the classes are in the project on both the My Computer and RT target side, the deployment will fail 100% of the time.

 

In order to get a successful deployment I have had to seperate the project into two different .lvproj files, one for the Windows system, and one for the RT system.

The RT system project contains only the top level RT program in it, nothing else. Even with this configuration if there has been a change to any of the dependent lvclass files, and more specifically any of the typedefs contained in the class, the deployment fails every time.

In about 50% of those cases if I manually open the vi that was loaded with errors and have it open on a subsequent deployment attempt, the project will deploy successfully.

The other 50% of the time will require a clearing of the compiled object cache, rebooting of the RT system, restarting LV, and another attempt at deploying. That process may have to be repeated 3-4 times to get a successful deployment. There is no active editing of the source code between deployment attempts, just the lather, rinse, repeat of the cache clear, LV restart and RT system reboot.

Eventually the project will deploy however there have been instances where it required repeating of this process for over 30 minutes to get a successful deployment.

 

The problem occurs under both the merged and split source/compiled code configurations.

 

A couple of other musings on this error.

In the cases where LV does show a crash window on exit, viewing the content of the error logs will sometimes show a particular VI that caused the crash. Opening this vi "occasionally" has the same effect as opening the "...loaded with errors" VI listed in the RT deployment dialog, and allows the project to deploy on the next attempt....sometimes not.

 

This thread was started in 2010, it has been 6 years since the original report and the problem still exists. It has manifested itself on all of the NI RTOS platforms (PharLap, VxWorks, and NI Linux RT), as well as the major RT targets (PXI and cRIO).

 

In 2013 Zach-H from NI (this thread, post 16) noted that there was a CAR generated for this issue, however there has been no update since that time.

 

NI, can we get an update on the status of this. As mentioned numerous times in this thread, this is a significant operational problem and results is large quantities of lost time.

 

Message 46 of 81
(3,743 Views)

 

Spoiler

gsussman wrote:

We have a large project (100+ classes) with some classes utilized on both the Windows and RT systems.

What we have found is that if any of the classes are in the project on both the My Computer and RT target side, the deployment will fail 100% of the time.

 

In order to get a successful deployment I have had to seperate the project into two different .lvproj files, one for the Windows system, and one for the RT system.

The RT system project contains only the top level RT program in it, nothing else. Even with this configuration if there has been a change to any of the dependent lvclass files, and more specifically any of the typedefs contained in the class, the deployment fails every time.

 It is interesting that my configuration is really close to yours when it comes to projects design

I also have:

- two projects (this is historical here, and not a design choice)

- shared classes between both projects (they consist in a Messaging layer, all classes being into a single Messaging.lvlib file, used by both projects)

- each time I modify a typedefed enum owned by one of my Messaging classes (by adding a value), I experience deployement issues

 

Looks like enum owned by classes are not properly "propagated"

Shame, because we want to use more LVOOP. NI had explicitely stated that they were mature. We do not experience this in our daily life


0 Kudos
Message 47 of 81
(3,719 Views)

Yes, it's appalling the way NI doesn't fix long standing bugs.

 

This particular one manifests itself in so many ways that it clearly shows that LabView is brittle behind the scenes. Almost to the point that one can't trust the product. This is terrible from a customer's perception because you can never give an accurate estimate of work; if you stumble on this you can't be sure how long it'll take to get out of it!

 

NI stance is very nonchallant. We pay maintenance fees to get bugs fixed and at one point was told I was wrong, that they had to spend (some; most of?!) that money to release new features instead... Well, I don't care about fuzzy icons (coming in LV2016), etc. If I want the new "features" I'd rather pay separately, if I find them worthwhile.

 

The forum is good, but NI thinks that the MANY workarounds found by us, suffice. We all need to keep pressure on our sales rep to get bugs fixed lest we stop paying maintenance fees.

 

 

0 Kudos
Message 48 of 81
(3,712 Views)

Yes, this is clearly a "propagation" issue. It is present in other areas of LabView as well. Sometimes I modify a typedef, select "Apply" on the menu and still end up with broken VI's that have the changes unapplied!

 

NI may think that the example above is a minor annoyance, but fixing it may shed light on why the one on this thread is happening. Bug fixing has to get started, though.

 

But... NI is busy creating (useless) "features".

 

I wonder what is the ratio (time spent, not number) of bug fixes versus new "features"...

0 Kudos
Message 49 of 81
(3,707 Views)

Hello all,

 

I am the Product Support Engineer for LabVIEW Real-Time here at NI, and I wanted to take an opportunity to address some of your concerns. Reading through this thread, I can say that I have seen issues similar to the ones you are describing. Our biggest challenge with these types of issues is that the “.vi loaded with errors and was closed” is a generic deployment error which makes it difficult to identify root cause based on the error alone. The likelihood of experiencing these types of deployment issues increases with application complexity, and as the average RT application has become more complex, we have seen an uptick in the frequency of reports of this nature. We understand how painful these types of issues can be to troubleshoot and manage.

 

NI is committed to debugging and addressing these issues and making customers using these features successful. Given the slow-but-steady increase in problems of this variety, we’d like to make greater strides toward addressing these problems. As such, we need code that demonstrates these bugs so that we can work to root-cause them. Reproducing cases are critical for us to drive further improvements in this area. When we actually have examples of code running into these problems, we can deep dive into the issue to attempt to identify the underlying cause. For example, most recently we addressed an issue related to circular dependencies when deploying large class-based real-time applications which resulted in this error message. This particular fix was included in the LabVIEW 2016 f1 patch.

 

With all of this in mind, I would encourage anyone experiencing issues like the ones described in this thread to contact support (ni.com/support) and open a ticket, or report a bug at https://sine.ni.com/srm/app/getassistance (log in, click “Report a Bug”).

 

You are welcome to reference this post during the support interaction if you feel it is applicable.

0 Kudos
Message 50 of 81
(3,610 Views)