When I intend to run my RT (communicating with an FPGA on a cRIO) it only runs one time. The second trial leads to the following error:
NI_AALBase.lvlib:Sine Wave.vi loaded with errors on the target and was closed.
LabVIEW: Failed to load shared library lvanlys.*:SineWaveCIN:C on RT target device.
After reseting the FPGA and Labview it runs again, but also only for one time.
Thanks for solutions!
It seems that something is corrupt when you run the application. So you should try to format the RT device and download the software again. Then run your application again. If it still fails you should upload your code to see what's going on.
By the way what is the exact version of LabVIEW and which cRIO device are you using?
I solved the problem by no longer using a sine creator on my RT, which it a sub.vi itself. I created my own sine generator that included no sub.vi and got no error so far.
I've exactly the same problem, with cRIO-9073 and LV-RT 2009. I've re-formated the cRIO & re-installed my project. Then it was working properly the first time, but after small modification in the code and a second deployement, it failed again, with this same error message "...Labview failed to load shared library lvanlys*...".
I realy don't know what to do now !
I have the same problem. I'm using a PXI1050 chassis and a PXI8108RT 24/7 controller and Labview 2011.
If I run all sub-VI of the code, every one run OK. But if I run the mai sub-VI this problem happen. I already formatted the PXI and deploy all the software again. It always happen when I change something in the software. If I save the SW with other name and don't change anything, it runs normally.
I really don't know what else can be done.
Have same problem.
There is any solution for this problem?
vi loaded with error on the target and was closed.
are you using Labview2011 with PXI and .llb extension archieves?
This combination didn't work. If you eliminate the library this error don't happen. I already talk with someone at NI about it, they told me that should be a bug at SW, but, anyone give me a reasonable answer.
Process (one day working on it!):
1- 'Disabled' .vi cutting it into small pieces.
2- Locate code that provokes 'not defined error' by enabling and running.
3- Finally located.
I've designed a communication system. To send data uses a PDU containing a 'variant' and 'ring'. This ring indicates type of data to convert variant with necessary typedef. The system defines 4 default msgs on ring (NULL, ACK, NACK, PING).
The receptor works well, but as I have a lot of data types, I need a case structure. (rings do not work with case at least on 2011) Then I do next thing:
Explicit cast to a typedef enum with all my data values... (This system is designed for our purposes and could not be the better solution)
... UNDEFINED ERROR ON PXI ...
Instead using explicit typecast use "coercion dot" casting. Like here.
I receive an U16 data that PXI cast to my enum on 'data out' indicator (you can't see coercion dot because pink and red are 'very different' colors)
No more errors.
Labview has issues working with explicit type-casting to enums. I can't work more on it, but is necessary to debug this kind of issues because can affect projects at last steps of the development and drives LVdevelopers crazy.
The only think I do with the enumeration is to add new element and all the system fails...
Thank you for your reply Schmitz!
I hope that this information could help somebody that in the future needs to investigate how LV works... xD
Probably this is not the only issue related with ".vi loaded with errors on the target" (known as the "well defined error").
In my case it had nothing to do with my code.
All I did was try to deploy to another unit and it worked. (Well, of course in the process LabVIEW "magically" asked me to save some other files that it NOW found "modified"...) Tried again on the original controller and everything was now fine...
That is buggy LabVIEW that only sometimes can figure out that a file has been "modified". The worst is that Support told me to start "Diagram Disabling" my code. NI doesn''t acknowledge this bug.