I'm pretty sure the FRC framework uses TCP (or maybe UDP) for all communication. I don't know if the FRC installation includes the Shared Variable Engine, and it adds some overhead so you might not want to use it even if it is available. However, if you're curious, here's the "Using the LabVIEW Shared Variable" document.
If you want to send data from your dashboard to the robot, and if the rules allow it, in my opinion the easiest approach is to set up a separate loop in your robot code that listens for UDP packets and writes the data received to a global variable. You could also do this with TCP, but UDP requires less work (at the very slight risk of some packet loss). Since you're dealing with fixed IP addresses and only a single connection (between the dashboard and the robot) the networking code is pretty simple for either protocol.
On your dashboard, start by opening a UDP socket using UDP Open (Data Communication->Protocols->UDP) outside the main loop. You can set the port number to 0 to get a random port. Inside the loop, take the data you want to send, run it through "Flatten To String" (Numeric -> Data Manipulation palette), then connect that string to UDP Write. Set the IP address to the address of your robot and pick a port number that you will also use in your robot code. When the main dashboard loop ends, close the UDP socket with UDP close.
In the robot code, open a UDP socket, but pick a specific port number (greater than 1024). Add a new while loop and put a UDP Read inside of it. Take the string output and connect it to Unflatten From String. You will also need to wire a constant of whatever type of data you expect to receive so that Unflatten knows how to interpret the string. Then, connect the output to a new global variable, which you can then read elsewhere in your code.
A couple of details: you'll want to check that neither UDP Read nor Unflatten From String returns an error before updating the global variable. You should also find a way to close the UDP socket when your loop completes. One easy approach is to set a timeout of -1 for UDP Read (wait forever). Wire the error output to the stop terminal in the while loop. Then, wire the UDP connection ID through your main loop as well, and close the UDP socket when the main loop completes. Then, when the socket is closed, UDP Read returns an error and the reading loop terminates. If you're really paranoid, you'll check that the data received comes from your dashboard, and not from someone else's. If Windows Firewall is running, it might ask you about allowing through your UDP traffic.
If you're going to take this approach, take a look at the UDP Sender and UDP Receiver examples.
