Here is my problem.
Hardware installation :
I have an RT target and a PC. The RT target have 2 ethernet ports on 2 different subnets. In my hardware installation the 2 subnets go from the RT target to the PC using Switchs. The goal is to always access the RT target from the PC if one wire ( or subnet ) is broken. I certify the installation is OK.
RT eth0 Subnet 1 : 169.254.239.1 RT eth1 Subnet 2 : 22.214.171.124
Actual software process :
On the RT target I have a process (communication loop) that send data using Network stream functions.
On the PC I have a process (communication loop) that read date using Network stream functions. The PC change ip config programmatically until the connexion (using Network stream) is established, so the connexion can be done to one of the 2 subnets of RT target.
To resume, PC ip switch from 169.254.239.10 to 126.96.36.199 until the connexion is established.
I would like to change the process using network shared variable.
On the RT target I write data to the variable called RT_DATA.
On the PC, i want to connect and read data from the variable whatever the subnet is.
I presume i have to use shared variable or psp shared variable functions.
If the PC change the IP adress, it's unpossible to connect to RT_DATA. How can I reconnect programmatically without rebuilding application ?
Thanks for your help.
Ouch! You are going exactly the opposite way that I went! When Network Shared Variables were first announced, I thought they'd be a much simpler way to stream data over TCP/IP (we initially didn't stream -- we saved data on the RT Target's disk, then ran an FTP command to copy it to the Host, very slow and problematic). I never got this to work reliably.
About four years ago, I rewrote the entire suite from the ground up, and settled on Network Streams. I used 4 streams -- two for bilateral Messaging between Host and Remote, and two for the Remote to stream data (analog, 16-24 channels at 1KHz, and irregular "Event" data (on average, 1-10 Hz) to the Host's disk directly. I also had a Network Shared Variable used to monitor parameters on the Remote, but it proved unreliable and buggy, so I gave it up.
I advise you to Stick with Network Streams (if for no other reason that they already Work for you).
You have another problem, however. At least one of your addresses is in the 169.254 subnet, which basically asks the Network (typically through a DHCP server) to assign an IP address. We also "used to do this", but when I saw these addresses, I immediately changed them to no-routing 10-dot (10.x.x.x) addresses. These are guaranteed to be "local" and "stable", which greatly simplifies the managing and "finding" of them.
If you have two Ethernet ports on your RT device, make them 10.0.0.100 and 10.0.0.101). You will also need a second NIC in your PC that you provision in the 10. range -- something like 10.0.1.100 (I assign all of the PCs addresses in the 10.0.0.x subnet, all of the remotes in the 10.0.1.x subnet, thus I minimize making "address" errors).
I don't know if this works with the RT Target you are using, but I use a routine in the RT Palette that finds devices on a Remote Subnet. If you tried that, you could just "attach" to the first IP that it found. Let me see if I can find that function ... I think it is called Find Systems (the name might have changed), but can be found on the RT Palette.