01-05-2017 02:30 PM
I tried accessing the lvlib on the PC from the VI on the cRIO on 3 different machines with 3 different cRIO-9075s. Two of the PCs worked just fine with the code in your original post. We never deployed the
The third PC was throwing the same errors you were seeing. We were able to write and read the shared variables successfully on that machine by programatically using a Read Variable VI (Data Communication >> Shared Variable >> Read Variable) without opening and closing the reference. The other workaround that we found was to use aliasing with the variable to read just as you have done with the write loop. Do either of these workarounds work on your machine?
Also what version of Windows are you using?
We were able to access the shared variable libraries on the PCs that do not have the problem from any of the cRIOs. That seems to isolate the issue to the PC and eleminate the cRIO as the source of the problem.
01-05-2017 03:25 PM
Programmatic access did not work but Aliasing worked!!! However, the primary intent of my original VI was to use the timeout feature of the NPSV to detect when the network is lost.
Is there a way to do timeout with an aliased indicator? Can you please let me know what address you used for programmatic access? it is very strange than an aliased indicator works, and when i right click it to change it to a shared variable node, it does not work. It is also strange how the DSM shows the correct value. it updates as i move the knob but the indicator in my VI does not.
I'm downloading LabVIEW 2016 evaluation to see if this solves the problem.
I am using windows 7 Professional, SP1, 64 bit. My LabVIEW is 2015 SP1 32 bit (i did 32 bit because build executable only works on 32 bit).
Programmatic Access
I tried right click the read NPSV and replace with programmatic access, which is the same as the 1st workaround described in the recent post "Read Variable VI (Data Communication >> Shared Variable >> Read Variable) without opening and closing the reference." This did not work. I then tried different "refnum in" values per the different host names in the distributed system manager
ni.var.psp://My Computer/Untitled Library 1/Variable1
ni.var.psp://localhost/Untitled Library 1/Variable1
ni.var.psp://Ryan-HP/Untitled Library 1/Variable1
i receive error -1950679035
Aliasing
I right clicked the indicator, data binding tab, selected Shared Variable Engine (NI-PSP), Access Type Read/Write, and path My Computer\Untitled Library 1.lvlib\Variable1.
01-05-2017 03:58 PM
The attached lvproj shows the NPSV timeout check i described to determine if the network connection is lost. It is nearly as simple as the original lvproj posted.
01-05-2017 04:31 PM
I think i found a critical clue. Please see the attached screenshot. The error -1950679035 had more info this time. I did cmd, ipconfig to check my wireless LAN IP address and my Ethernet adapter IP address. The labview popup for error -1950679035 shows the NPSV is referencing my wireless IP and not my ethernet IP, even when my wireless is disabled.
Do you know how to programmatically specify an IP address? the refnum format for a shared variable address does not include the IP address.
Variable URLs must take one of the following three forms:
(1) [Variable Engine]://[Host Name]/[Container Name]/[Variable Name]
(2) //[Host Name]/[Container Name]/[Variable Name]
(3) /[Container Name]/[Variable Name].
01-05-2017 04:43 PM
The previous post was run with wireless enabled. However, i corrected all the IP references and disabled wireless. it still doesn't work.
i disabled wireless. I then right clicked my computer within the lvproj and specified a custom address as the ethernet address: 192.168.1.5. I redeployed everything in the project and then ran the programs. i now get the same error -1950679027 but with the correct IP in the error description "Shared Variable in VI_cRIO.vi<APPEND>
This error or warning occurred while reading the following Shared Variable:
\\My Computer\Library_PC\NetCheck_PC
\\192.168.1.5\Library_PC\NetCheck_PC"
01-06-2017 10:09 AM
Aaron,
I realized my mistake. I had turned off the firewall for only private networks while i was connected to a public network, so the firewall was never turned off. When i turned it off for both networks, it worked!!!!!!!! what a relief. i seem to always get caught up on simple things.
I validated it worked with a crossover cable and with a router.
I went back to the "Allow programs to communicate through windows firewall" list and made sure each NI program and feature was allowed on both private and public. Now it works all the time!
01-06-2017 10:17 AM
Ryan,
Glad to hear it! Networking problems can be tricky to troubleshoot. Thanks for posting the resolution.
Have a great day,