Hello again all you helpful forum-goers!
I have run into a very strange situation involving shared variables and the file system on a real-time target. One of my network-published shared variables, all of which are hosted on the real-time target of a Hypervisor computer (one which has some cores running the real-time OS, and some running Windows), seems to have a value stuck in it even though I have changed the value and restarted the entire computer.
The shared variable in question is called Network Config, and it is a cluster of integer values representing the IP address and UDP ports I am using in my application. The value in question is the UDP input port. The value which seems to be stuck in that variable is 52274.
Test #1:
I have used the Windows side of my application to change the shared variable to a different value (e.g. 52277), and I can see the code on the real-time side has changed to use that value (it receives UDP on the new port and no longer on the old port). Also, my real-time code writes the network configuration settings to a file on the real-time side whenever they change, as the Windows side of my application is optional, and the real-time side needs to work with the latest setting if it is started up without the Windows side ever being opened. When I changed the value to 52277, I used Internet Explorer to look at the file system of the real-time target, and I could see the settings file was updated to have the new port value. I exited Windows application, checked the real-time file again to verify it still showed the new value (it did), then restarted my whole computer. When the computer finished restarting, I looked at the real-time settings file again using IE and saw it had changed to 52274, and I can verify my real-time code was using that value.
Test #2:
I changed the name of the real-time settings file slightly, rebuild and deployed my code, restarting the real-time side through the LabVIEW development environment. My file access VI has a case for if the file is not found, it uses default values, specifically 52271 for the UDP input port, so it should have gone to that. After it finished restarting, I looked at the file folder using IE, found the new settings file name, and it had 52274 as the port number. Grr!
I have done a search for 52274 throughout my real-time code, and it was not found (52271, the default in the file not found case, was findable for reference). So my only remaining idea is something with the shared variable engine not really restarting even when I restarted my whole computer? I just don't know anymore. I have attached the network communication VI for my application, with the VIs that actually do anything with the data removed for proprietary reasons, so you can see my logic for when to read/write the settings file, along with my settings file access VI.
If anyone has any ideas as to what could be going on here, I'd be very grateful for them!
Thank you,
-Joe
P.S. Note that the conversion dot is because I use a typedef version of my Network Config cluster everywhere except for the shared variable (since they cannot use typedefs), where I use a identical copy saved as a normal control instead.
P.P.S. Note also that although this VI doesn't show it, on the remote computer where I am actually using these VIs, I have added additional code to ignore a new value from the Network Config shared variable if the error code coming from that variable is non-0; in that case I just keep the value coming from the shift register. I'm not sure if that is helping at all, so I haven't added it to my primary source file on my computer, which is what I am attaching. The point is, doing that doesn't seem to be helping.
[Edit] P.P.P.S. My browser doesn't seem to be allowing me to actually attach my VIs. (Grr) I'll talk to my IT department to try to get that fixed ASAP and get them posted.
