01-17-2011 12:55 PM
Hardware setup:
Laptop
cRIO
NI vision writes to the variable on the cRIO. I can see the variable properly updating in system manager on the cRIO. I can also run a VI in my computer that shows the variable properly updating. But...... When I read the variable with a VI running on the cRIO, I get the folowing error and the variable never updates:
Error -1950678968 occurred at Shared Variable in Main.vi
Possible reason(s):
LabVIEW: Failed to load nitaglv, which is required for Network-Published Shared Variables.
This error or warning occurred while reading the following Shared Variable:
\\NI-cRIO-OASIS\cRIOVariableLib\BubbleDiameterFromVision
\\192.168.0.1\cRIOVariableLib\BubbleDiameterFromVision
(I do not get any errors at deloyment)
So everything (NI Vision, a VI deployed on the laptop, NI Distributed System Manager) can see the variable on the cRIO being updated by the NI Vision.... Except for a VI running on the cRIO.
I have verified that I have Network Variable Engine and Variable Client Support for RT installed on the cRIO. I have tried reinstalling all s/w on the cRIO. Tried rebooting all. And talked in a nice, positive, reassuring voice to the chassis.
01-17-2011 01:03 PM
Tried something even more simple, just made a new variable in the project on the cRIO. Without writing anything to it, created a new VI and tried to read it and got the same exact error above.
01-17-2011 02:35 PM
Tried using different LV license and reformat/reinstall of s/w on cRIO. Still getting same error.
01-19-2011 09:29 AM
Hi Brad,
Do you get this error if you were to create a new project with a simple target VI that shares a value via Shared Variables? I'd like to know if this is a problem with one particular project, or perhaps an installation wide issue.
Do you get the same error if you host the library on the Host PC instead?
01-22-2011 09:33 AM
I did finally get it working. I had tried reinatlling software everywhere. I did try changing the variable to be hosted on the laptop host. The project I had was incredinly simple... just a shared variable really. I then went ahead and created a whole new project from scratch and it works now. Is this some sort of corruption issue in the project? Not a big deal this time, because the project was so simple, but if had a lot of effort in the project, it would have been a real problem. Is it possible to fix this behaviour in a corrupted project?
01-24-2011 04:14 PM
There isn't usually a quick fix for corrupted projects or VIs. There are a few tricks for retrieving and copying data from certain types of corrupted VIs or Projects, and if you have a reproducible corruption case, R&D is glad to look into the issue. But, those cases notwithstanding, corruption can be caused by a host of issues, and is rarely a neat problem.
I'm glad you were able to work around the issue.
All the best with the rest of your project.
06-03-2011 05:40 AM
Hi!
I just had the same issue with my cRIO 9073 using NI RIO 3.6.0.
The problem is not caused by a corrupted project, but the improper installation of the OS on the target. There is nothing you can do using the SW installation wizard in MAX, as it does not matter if you intall a full RIO SW, minimal or custom.
You have to install the full install or a custom one with Shared Variable support. Then you have to FTP to the cRIO, and manually edit the "ni-rt.ini" file located in the root of the controller.
Make sure you have a line in the "[MODULE VERSIONS]" section which shows the version of the nitaglv.out file. (The problem is caused because this dll is not loaded when you try to access a SV) Mine looks like nitaglv.out=6.3
Then you have to insert "nitaglv.out;" without quotes to the [LVRT] section's StartupDLLs key's value. I did it after the taggerrt.out name. So my key entry now looks like this:
[LVRT] StartupDLLs=nisysapirpc.out;NiViSrvr.out;NiRioRpc.out;taggerrt.out;nitaglv.out;sysstatepublisher.out; memoryChecking=False LABVIEWRTDir=/c/ni-rt/system PATH=/c/ni-rt/system/;/c/ni-rt/; CDIntervalTicks=55 WebServer.Enabled=FALSE RTTarget.VIPath=/c/ni-rt/startup RTTarget.IPAccess=+* RTEnetRcvMode=2 RTCPULoadMonitoringEnabled=True RTTarget.ApplicationPath=/c/ni-rt/startup/startup.rtexe server.tcp.access="+*" RTTarget.LaunchAppAtBoot=True RTTarget.EnableFileSharing=True server.tcp.serviceName="Main Application Instance/VI Server"
After you are done with the editing, you have to save the file, and overwrite the original one. You have to reboot the controller for the modification to take effect.
After this you will be able to host your variables on the cRIO and also read/write them from the application running on that same target.
I hope this will help for you too.
Regards,
Peter
06-03-2011 08:52 AM
No way! You should not need to do any manual file installations to get SV's to work on a cRIO. My guess is that you have
some sour mix of LV dev. software on you machine. I am using LV2010SP1 with NI-RIO 3.6.0 and Network Variable Engine 1.7.1 and it work perfectly right from the standard
NI-RIO 3.6.0 with NI Scan Engine support - January 2011 installation set.
06-03-2011 09:03 AM
I will see if I can go dig up the corrupted project I had. and try this. The interesting thing though is that starting fresh with a new project fixed it. If I run into again, I will deifintly check the ini file though. Its defintly not due to a mixed/incompatible OS load though in MAX. I must have tried reloading the the OS fresh ten times and could not get anywhere.
06-03-2011 09:20 AM
I can personally attest to the fact that project corruption can and does happen. I have seen it cause all manner of nasty problems in NSV and IOV access.
The solution is to create a new project and try draging folders from the old project to the new. Not all folders will copy this way but most do.
I really think NI should consider creating a utility that will copy and verify a project.