LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ftp and 2 network cards

I have an XP system with 2 network cards.  One is for communications between the computer and a test frame controller and the other is for our company LAN.  The order of how the cards are accessed is fixed.  The  test frame controller is accessed first in order for the test sotware to function properly and the company LAN second.

Here is the problem.  I have written code using the Internet toolkit, FTP vi's to transfer files to a UNIX server.  With the current accessabilty order of the network cards, I can not connect to the ftp server.  If I switch the order of the network cards, the ftp program works fine.  As I have stated above, the order of the cards needs to remain fixed for the test system to work properly and I don't want the users going into the network connections settings and switching the order of the network cards.

Is there anyway to tell LV to use a specific network card?

Some other information: both network cards have differnt IP adresses, but the same subnet address.

Thanks in advance.
0 Kudos
Message 1 of 11
(4,851 Views)
Perhaps you could describe your network topology a little more. Is the test
frame controller and you computer connected with a crossover cable? Is the
test frame controller also on the company LAN? If the test frame controller
is connected with a crossover cable or on a separate network from the
company LAN, you should be able to assign it and the network card in your
computer for that network to a subnet address different from the company
LAN. I think the common practice, at least for us, is to use the subnet
192.168.x.y. You can use 255.255.255.0 for the subnet mask to further
divide the subnet address space. As long as the subnet portion of the IP
addresses assigned to your network cards are unique, LabVIEW should have no
problem using the correct card. As an example, let's say your card for the
LAN is assigned 155.459.8.5, submask 255.255.253.0, and your other card is
192.168.0.11, submask 255.255.255.0. If the test frame controller is
192.168.0.12, LabVIEW, and any other software using TCP/IP calls, should
have no problem selected the correct route.

"BB Herman" <x@no.email> wrote in message
news:1130179237006-281106@exchange.ni.com...
>I have an XP system with 2 network cards.&nbsp; One is for
> communications between the computer and a test frame controller and the
> other is for our company LAN.&nbsp; The order of how the cards are
> accessed is fixed.&nbsp; The&nbsp; test frame controller is accessed
> first in order for the test sotware to function properly and the
> company LAN second.
>
> Here is the problem.&nbsp; I have written code using the Internet
> toolkit, FTP vi's to transfer files to a UNIX server.&nbsp; With the
> current accessabilty order of the network cards, I can not connect to
> the ftp server.&nbsp; If I switch the order of the network cards, the
> ftp program works fine.&nbsp; As I have stated above, the order of the
> cards needs to remain fixed for the test system to work properly and I
> don't want the users going into the network connections settings and
> switching the order of the network cards.
>
> Is there anyway to tell LV to use a specific network card?
>
> Some other information: both network cards have differnt IP adresses, but
> the same subnet address.
>
> Thanks in advance.


0 Kudos
Message 2 of 11
(4,843 Views)
DD,

There is no cross over cable and the test frame controller network card is seperate from the company LAN.  Instead of an RS-232, IEEE, USB, etc. communication link, the vendor has chosen to incorporate its communication protocol via a network card.  It is independent of the LAN.  Its sole purpose is to provide the communications link between the testing/control software and the test frame.  There are only 2 network cards.

As I stated previously, the order of the cards must be fixed.  The network card for the test frame must be accessed first in order for the test software to function properly; otherwise the test software tries to access the LAN and then shuts down the test frame.

I have written a simple vi that reads the computers IP address.  If the LAN card is first in the access list then the vi finds this one and when I make the test frame card first the vi finds that one.  So it seems LV uses the first card in the access list.  I need to be able to tell LV which card to use.  Can this be done?

As a note, if I open a DOS window, I can run ftp manually and everything works fine no matter what the access order is.  Therefore Windows can some how resolve which network card to use, so I would think LV should be able to do the same.
0 Kudos
Message 3 of 11
(4,828 Views)
If you have two separate networks, and proper addressing, I do not think you
should have a problem with the order of the NICs in your computer. I have
never encountered such a situation. Every one of my lab computers has two
or more NICs. How is the computer connected to the test frame controller?
If it isn't with a crossover cable, are you going though a hub? I would
normally expect a direct NIC to NIC connection with a crossover cable, with
these NICs using addresses in the range from 192.168.0.2 - 192.168.0.253.
Since the LAN would be on a different subnet, both physically and as
indicated by the addressing, LabVIEW should not try to use the wrong NIC to
talk to the TFC.

Just to make sure I'm addressing the correct problem, is the issue being
able to talk to the test frame controller or is it the order in which
program execution occurs?


0 Kudos
Message 4 of 11
(4,827 Views)
The NICs are connected with direct cables (maybe this is what you are calling a crossover cable) one from the pc to the test frame controller and the other from the pc to LAN drop.

It's not the physical location of the cards in the pc either.  If you right click My Network Places and select properties.  Then select Advanced from the menu and then select Advanced Settings you get a list of connected networks and the order in which they are accessed by network services.  On our pc we have the following order: 1. Local Area Connection (which is the NIC for the test frame) and 2. Local Area Connection 2 (which is our company's LAN).  This order is fixed by the vendor's software requirements.

The problem is being able to tell the TCP Open Connection function which network card to use in order to connect to the LAN and communicate with our ftp server.  For when I use the funtion TCP Open Connection it seems to default to whatever the first network in the above mentioned list is, which for us is the vendor's NIC.   It never sees Local Area Connection 2 (our LAN).  If I switch the order, my LV ftp program works fine.

Is there away to tell the TCP Open Connection function which network card to use?
0 Kudos
Message 5 of 11
(4,801 Views)

Which NIC to use is a decision that the OS makes. I too have had no problems with two different NIC cards and just specifying the correct ip. Windows can do some strange things though (especially 2K and XP) with network connections. Have you tried assigning a unique subnet? One thing to try is to add a persistent route. From the DOS prompt, the command is ROUTE ADD Destination MASK netmask Gateway -p. Check to see if Windows has already created any persistent routes that might be screwing things up by doing a ROUTE PRINT. Another thing that can cause problems is a temporary disconnection of one of the network connections. I have a NIC dedicated to a UUT and the network connection is lost when the UUT is not powered up. If windows boots up without the connection present, the NIC is disabled. There's a registry entry you can make to disable windows media sense. Details are at http://support.microsoft.com/default.aspx?scid=kb;en-us;239924&Product=win2000.

Message 6 of 11
(4,795 Views)
> Is there away to tell the TCP Open Connection function which network card
> to use?

Yes. You do it indirectly when assigning the IP address and subnet mask
which together establish on which subnet the NIC resides. When trying the
open the TCP connection, the IP address of the destination is examined to
determine to which subnet it belongs. If the destination isn't on a local
subnet, a router must be used to find a path to the destination.

A dedicated ethernet connection to a single device is generally done with a
crossover cable. This cable has the send and receive signals crossed over
in the cable. If more devices will be connected to the same subnet, then
all the devices will be connected to a hub or ethernet switch with straight
cables. In this situation, the hub or switch crosses the send and receive
signals.

If this network will not be connected to a router or to any hub or switch
connected to another network, then you really can use any range of addresses
you choose. But to avoid confusion, perhaps, addresses in the range of
something like 192.168.x.y are reserved for isolated networks. To avoid any
problems, the NICs of all of the devices on the isolated network should be
addressed such that they are all on the same subnet. There might be a way
to use addresses which are not all on the same subnet, but that is beyond my
level of understanding. The subnet is determined by ANDing the bits of the
IP address and the subnet mask. So, if the subnet mask is 255.255.255.0,
make sure that the first three fields of the IP address are identical. For
example, one if my subnets is 192.168.0. The fourth field should be from 2
to 254 (1 is typically used for gateways and 255 I think is used for
broadcasting).

For all devices on this isolated, simple network, two fields of the address
properties need to be manually filled in; these being the IP address and the
subnet mask. The gateway address isn't needed since there is no router and
the domain name server (DNS)address isn't needed if IP addresses instead of
URL names are used.

The addressing for the company LAN, especially if it is connected to the
internet, has other requirements that are probably specified by your
company. You probably don't have the freedom to choose addresses as you do
with your connection to the TFC. If these address are manually entered,
make sure that the subnet for the company LAN does not match the one you are
using for the TFC connection. Again, you do this by ANDing the bits of the
IP address and the subnet mask. Be careful with the company LAN subnet
mask. My company, in a quest for more address space, uses 255.255.252.0
instead of 255.255.255.0 for the mask. If the company LAN uses DHCP, and IP
addresses are assigned automatically, I think you can see the dynamic IP
address and subnet mask with the "ipconfig /all" command in a CMD window.
If the company LAN and the TFC connection are on the same subnet, I
speculate that the TCP Open Connection VI might not think there is a need to
try subsequent NICs in the list of connections. Apparently you've found
that FTP running in a CMD window doesn't make this assumption.

Please confirm that your addressing scheme adheres to these guidelines. If
it does, then we need to dig further to find the source of the problem.
Also, you mentioned that the vendor's software specifies the order of the
connections in the Adapters and Bindings list. Is this from a manual or has
this been determined by use? If these are the vendor's instructions, could
you post the relevant sections to help me understand your situation?

Also, to reiterate something Dennis said, make sure the network cables are
plugged in and all devices powered up when you reboot your PC. These things
should be plug and play, but I've had inconsistent problems if I don't do
this.

As a
Message 7 of 11
(4,781 Views)
If the company LAN and the TFC connection are on the same subnet, I
speculate that the TCP Open Connection VI might not think there is a need to
try subsequent NICs in the list of connections.

I think we may have stumbled onto the root cause.  The LAN and TFC are on the same subnet.  So I changed the subnet for the TFC and the TCP Open Connection still goes to the first NIC in the list.  It appears there is a limitation with
TCP Open Connection being able to resolve which NIC to use.

Any suggestions are where to go next?  Any idea how Windows is able to resolve which card to use?
0 Kudos
Message 8 of 11
(4,758 Views)
I'd like to take a look at the output of the "ipconfig /all" and "route
PRINT" commands from your PC, and any documentation from the TFC vendor on
how to set up network addresses. I'd also like to see the addressing
settings for the TFC and the port numbers you use for the TCP open
connections, both for the FTP connection and the TFC connection. If you
want to do this, let me know and I'll send you my e-mail address. In the
outputs, you should edit out the last three fields of the ip address, the
default gateway, and the DNS servers of the Ethernet adapter you use to
connect to the internet, since I don't really need that part.

It also occurred to me you might try giving the TCP Open vi an URL name for
the FTP host, forcing it to look for a DNS. I don't know if this will work,
but it doesn't take too long to try.

"BB Herman" <x@no.email> wrote in message
news:1130438454032-282579@exchange.ni.com...
> If the company LAN and the TFC connection are on the same subnet, I
> speculate that the TCP Open Connection VI might not think there is a need
> to
> try subsequent NICs in the list of connections.
>
> I think we may have stumbled onto the root cause.&nbsp; The LAN and TFC
> are on the same subnet.&nbsp; So I changed the subnet for the TFC and
> the TCP Open Connection still goes to the first NIC in the list.&nbsp;
> It appears there is a limitation with TCP Open Connection being able to
> resolve which NIC to use.
>
> Any suggestions are where to go next?&nbsp; Any idea how Windows is able
> to resolve which card to use?


0 Kudos
Message 9 of 11
(4,754 Views)
Sorry it took so long to get back to you, but I needed to get approval from our IT people before releasing any information.  Anyway they said it was OK.  If you give me your email, I will compile the data and send it to you.  Thanks.

The url option did not work either.
0 Kudos
Message 10 of 11
(4,726 Views)