UDP ip address

[CNJ]

I have two ethernet PCI cards in my PC.  One of them is gigabit (Intel PRO/1000 GT) and the other one is 10 BASET.  I found a couple of functions, i.e., UDP Write and UDP Read in my Labview 6.0 which may work for my purposes.  I was able to set a unique IP address for each of the PCI cards.  Each of these cards will be used to communicate with a unique remote device (therefore a unique IP address).  I see that in UDP Write and UDP Read, there is a way to specify the IP address of the remote device.  I don't see how I can associate the IP of my PCI cards with the UDP Write and Read functions.  I have fixed the routing table.  Now the missing part is "how may I send a UDP message out via a particular PCI card or receive a UDP message via a particular PCI card.  Thanks for your help.   

[smercurio_fc]

Which card gets used should be automatically selected by the OS, assuming you've set up the cards to be in different subnets and have the proper routing tables.

[PhillipBrooks]

You can specify the network address to listen for UDP datagrams on when you use UDP Open (LabVIEW 8.20 and later). This would require opening a reference for each network card. There was no way to do this before 8.20.

I believe LabVIEW will perform the UDP Write using the network card specified when opening the connection reference, but I am not positive. Maybe someone from NI can confirm this?

[CNJ]

I found the problem that caused my transmission to not work.  I knew that the route table was not persistent, so I made a script to correct the route table every time I wanted to use the two ethernet PCI cards.  What I didn't know was that the gateway "interface" changes with every power cycle of the PC.  So I had to do a "route print" in the command window and look for the interface (IF) specific to the gateway I'm using and replace my new current IF with this new IF in the script.  I tested my UDP send function and it works now.  I assume the UDP receive function works in a similar fashion.      

[smercurio_fc]

It doesn't make much sense that the gateway address would change with a reboot unless you're using DHCP, and that address was being pushed down through the DHCP protocol (which you can do).

[NathanK]

Phillip B,

It is true that specifying the address of the local network card in the UDP open will cause it to be used for the UDP Write as well. In practice this is only really useful when the cards are on different subnets and you are doing a UDP broadcast so the networking stack can't figure out on its own which card to use.

[CNJ]

smercurio,

You're probably right about the interface.  I tried power cycling a couple of times this morning and the gateway persisted!  So now I don't know why the gateway changed that one time.

[CNJ]

I've been trying to make UDP receive work in LabView 6.1 to no avail.  I noticed from Philip's comment that there's no way to specify an IP address to listen on in the "UDP Open" function until version 8.20.  Does anyone know if there's a way to specify this via Windows 2000 instead of LabView?  I wonder how it's done prior to LabView 8.20.  I can't imagine that this is something we just hook up and pray that the OS would assign the IP address we want.  I see that my UDP Read currently listens on 0.0.0.0:port #.  I can't figure out how to make it listen on "My ip address: My port."  Upgrading to Labview 8.5 would be my very last resort since it would involve tremendous amount of work and risk.  Thanks for any input and help.     

[NathanK]

CNJ,

What Philip was saying is that before 8.2 it was impossible to specify 1 particular interface to listen on. If the UDP Read is listening on 0.0.0.0 that means it will listen on ALL of your interfaces on the port that you specify.

If you aren't receiving any data, the fact that the UDP Read is listening on MORE interfaces than necessary is not likely to be the source of the problem.

Again- unless you need to listen on one interface and not the other, it won't be necessary to upgrade to 8.2.

[CNJ]

Figured out the problem.  The destination MAC address as specified in the incoming message was wrong.  Thanks to all who helped.