Real-Time Measurement and Control
.vi loaded with errors on the target and was closed
I've got the same issue, since I'm working with LabVIEW 2017, classes, and RT targets.
Last week, I had this issue when I changed a typedef included in another typedef.
Luckily, I realized when I saved it that something didn't get as usual (I don't know how, something about the way the front panels are refreshed at save), then, thanks to this post, I realized that there were effectiveley something weird with my typedef changing, but I was unable to find somehing changed on it, and no way to update it manually.
If I remember well, I removed the Typedef I changed in the calling Typedef and included it again. probably had some popup saying to revert changes, several times, but I succeded to have it downloaded right.
Today, I just added some items into a typedef ring, not included in any other typedef.
Then, trying to run it on my RT target (where the same project was already running as an rtexe, without the ring updated), it showed issue deploying the VI (a class method containing a subVis containing the updated ring).
Also, a lot of VIs are seen as already deployed, even if I stop executing the rtexe at startup and restart the RT target hoping to deploy from a clean environment, because I expect that typedef in memory on Rt target is somewhere close to the issue.
Nothing changed.
I also tried to click "open typedef" from all instances of it on subVIs, and some of them was saying that typedef changed and asked me to revert. Then, saved the class containing the method, and deploy again without success.
btw, If I found quite understandable the revert popup when I've seen it in the past, since I'm working with classes, I feel it nonsense, and poping everytime without reason. There is something to work with Class saving and typedef cash to propagate changes when done.
As far as i'm going to add a lot of items to this Ring as I develop, I would like to be able to run my code each time, and not losing a complete day trying to make it work at each modification.
Maybe something that could help understanding the issue, I have a main VI, wich is the method of a class (using Messenger Library from JDPowell, and its actor class). This main lauches several other actor processes, and I develop all those classes on a project on my computer.
Then, I use another LV project where I declared my RT target and declared only the Main class on it (all other classes are in dependencies). Could this explain something with the updating process of typedef in dependencies?
I just succeeded to deploy my Vis again.
I'm not sure of what I've done, but I guess I closed my project, open only the class with the method not succeeding to deploy.
Open the method and I did a CTRL-Shift-Run (wih no hope as I already did a lot of mass compile before).
Then the VI was marked as changed so saved it.
And I could finally deploy my main VI with success
Still an issue with 2018. I reopened a project I'd opened many times before that is relatively simple with I think only 3 or 4 classes. Run failed pointing to a VI that wasn't broken. I started disabling parts of the code until it would run, I was done to a single build array node. If I disabled it it would run (but not run right of course I needed that node). I then created a new build array, and it would fail. I added always copies, moved functions around tried all kinds of things. Eventually I got this VI to deploy by using an array constant and a replace array subset giving me the same functionality. But then other VIs wouldn't deploy and disabling a single IPE structure meant it would run.
I cleared compile cache, restarted RT, disabled RT startup, restarted LabVIEW, forced a recompile, nothing seemed to work. I did rename the offending class and it ran fine. I renamed it back and it was back to not running. I was getting ready to format my controller when all of the sudden it started working after a few more restarts and clearing compile cache. The code isn't the problem, it is how LabVIEW is using the code. Possibly constant folding being too aggressive, or some other compiler optimization. When it happens it is on that system, and it is hard to convince LabVIEW to deploy it right. Is there some INI key that forces a more full compile or deploy operation? A quick search didn't find anything.
For people reproducing this behavior, do you eventually use "Simple error Handler" in your code?
I'm facing again this behavior, and I'm trying hard to workaround it since several hours without success, but here is what I've discovered, and I wonder if that could get a clue :
When I run my RT VI, I have a VI failing to download. This VI is from a class in a framework, that I never changed, wich permits to load dynamically all processes I'm developing.
Trying some Mass Compile, Clear Compiled Cache, rebooting targets, and so on, after reinstalling one of my target, I've seen the failing VI broken (where it was never broken before).
The broken arrow was claiming that one of my VI was broken, but it was a VI that is inside a "Diagram disable structure" in the disabled case, so it should not have impacted any calling VIs. Whatever, I removed it and the failing VI was not broken anymore (but still failing to load).
I then realized that if I open the Error List (Ctrl+L, or View>Error List), I have some VIs coming from the Simple error handler wich show not supported function for specified target (even if the arrow is not broken).
Those particular functions are in Conditional disabled structures and should be disabled for RT Targets. But with the behavior I've seen just before where a VI was broken because of a bad VI inside a disabled structure, I'm wondering if this could get a source of the issue, where in certain conditions, LabVIEW sees those disabled functions as if they were not really disabled ??
Thanks for your feedback.
Hi All,
My last message disappeared, so I put a simplest one.
I wonder if some of you are using "simple error handler" in their code?
Looking at error List (Ctrl+L or View>ErrorList), I've seen that some VIs from Error Handler appear in Error for being not supported for current target.
But I get an issue with a VI that is failing loading to the target and doing lots of manipulation, I finally succeeded to see it really broken, and this was because of a broken VI inside a "Diagram Disable structure", so I should not have seen the broken arrow in this conditions.
Then, I'm wondering if that could be a clue or not.
Another point, is that I regularly see some ogtk (OpenG toolkit) VIs being saved with my project, as if they were continuously changed. Do you use this kind of VIs ?
For the moment, I'm again having hard work on trying to get my code downloadable, without success for 2 days now. I thought I found that I had effectively changed a typedef, but even removing it, resynchronizing it, and lots of other Clear Cach, Mass Compile, don't permits me to launch my code again.
My code is working weel on a computer and on a PXI-8106 but don't want to load on cRIO-9082. (I use the same code, but in 3 different projects, one for each target)
Other observations:
- Recently, when facing this issue, I was able to workaround the issue by Building a real-time application, run it at startup, then, loading the code in debug (stopping the RT exe) was making the load successfull.
For now, I'm completely out of ideas to get out of this situation.
- I also realized that I often have a popup when I want to close my project, saying that some VIs are stil lrunning on the target, and asking me if I want to close them or disconnect.
But my code is supposed to close all modules it launch, and this popup should not appear.
Is there a way to know wich VIs are still running on the target?
Do the use of lv classes could explain this kind of behavior? (maybe something staying in memory)
