I was looking into a TCP connection, and can understand everything except for the remote port or service name. What am i supposed to put there? does it not matter as long as it is the same? do they have to be different?
If you think of the IP address as the street address, the port is like the apartment or door number. For a given machine they need to match, but if they use the term outgoing port, that refers the sending computer’s port.
Service names are a way of using names and letting the port number be dynamically assigned. Quite a few port numbers are reserved for a given service. It is worth reading Wikipedia on tcp/ip to get a better sense of which to use. In LV, an unwired port will be dynamically assigned to avoid a conflict and is typically the right thing for outgoing ports
Greg McKaskle
can you post example code please?
I’m not sure what you want demonstrated with example code, but I’ll try and explain in different terms.
The input “Remote Port or Service Name” can take two inputs, an integer, or a string. When given a number, this is the TCP/IP Port on which to operate. So if you want to send/receive data on port 21 (commonly used for FTP), you would wire a numeric constant with the value of 21 to that input.
If you provide a string input, LabVIEW will query the Service Locator and try and resolve your input to an existing service (which will correspond in turn to a port number). In reality, you can avoid using the Service Locator portion of this input, providing you already know which port you need to use.
I’m pretty sure NI has some examples provided in the TCP/UDP sections of their examples (go to Help->Find Examples, you can search for “TCP”), and they’re usually pretty helpful.
so the port can be any number than, as long as it matches the other computer’s?
There are ranges of ports that are reserved, and some low numbered ones that are owned by things like ftp. But yes. Use the same number for both, as the examples do, and it should work.
Greg McKaskle
what number would you say is the lowest i could do (or any safe one)
Ports that are guaranteed open on the field (from the manual):
Once plugged in to the Field Management System via the Ethernet cable provided, the ports that the teams will be able to access on the playing field are as follows:
– TCP 1180: This port is typically used for camera data from the cRIO to the DS when the camera is connected to port 2 on the cRIO. This port is bidirectional on the field.
– TCP 1735: SmartDashboard, bidirectional
– UDP 1130: Dashboard-to-Robot control data, directional
– UDP 1140: Robot-to-Dashboard status data, directional
– HTTP 80: Camera connected via switch on the robot, bidirectional
– HTTP 443: Camera connected via switch on the robot, bidirectionalAll these ports are open on the playing field, so a team can use them as they wish if they do not employ them as outlined above (i.e. TCP 1180 can be used to pass data back and forth between the robot and the DS if the team chooses not to use the camera on port 2).
If you’re not planning to use this on the field, then you have a lot more choices. If you’re operating in a closed system (with only things you control talking on the network, i.e. your robot), you can basically pick any UDP port you want. I like to use 1124 (for obvious reasons). The only ports where other things might be operating are TCP 80 (HTTP), TCP 21 (FTP), and 22 (SSH). Basically, you can use any port not already in use on the network (which very well may be any port you want).
i want to get a picture from the camera by an onboard laptop, do some processing, and then send information out to the crio to read. So not dealing with any network. So is it still limited?
You should just use WPILib to read the camera’s stream on your laptop, this shouldn’t be a problem for you, right. This will use TCP port 80 underneath. When you send data to the cRIO, I’d use UDP on any port, except 80, just pick one that isn’t already in use (and yes, I know that TCP 80 and UDP 80 are technically different, but just avoid that port and make things simper, it’s not like you’re all that constrained).
udp not tcp?
If you’re just sending data between two computers, you don’t need the handshake because, if a packet is dropped, another one will be sent very shortly thereafter. It’s the same reason the driver station/robot communication uses UDP, as well.
oh ok so TCP is only for if you need to send data making sure that it arrives correctly with no error. For example, a messaging program, right? But since it will be updating information constantly, it doesn’t matter if it gets there or not, because right after it a new one will come in. Is this right?
That is correct.
ok thank you so much. I think i understand it now. +1 for reputation 
Wonderful, I’m always happy to help (and sometimes learn something new in the process). Don’t hesitate to shoot any other questions my way, should they arise.