Help with PXI real-time to WinXP host direct connection using crossed network cable?

[Frenk]

I have written TCP software to pass data back and forth between an 8176 PXI real-time controller and a Windows XP host. Both machines use static IPs that differ only in the right most octet.

When connected to our LAN, the software works beautifully. For experiments however, I need to directly connect the machines in order to avoid unknown delays associated with other people's network traffic on the LAN.

If I use a crossed network cable to directly connect the machines, I can initiate a data acquisition, but the connection to pass data back to the host times out.

Are there tricks to getting a direct crossed network connection to work? I suspect its a windows XP problem (but no fi
rewall is being used).

Thanks in advance for any help,
Frenk

[Bob_Preis]

Check your subnet mask. If it's 255.255.255.128, make sure both IPs are in the same half of the last octet.

You might also try removing the gateway IP, since it's only unnecessary when the hosts are on different subnets.

[RobCole]

Can you initiate an FTP session using the cross-over cable? If not, then the problem is probably in the cable. You might also try targetting to the PXI to check the connection. Checking that the cross-over cable has the pairs 1, 2 crossed to 3, 6 and vice versa woul dbe the next step ( I usually cross 4, 5 and 7, 8 as well just in case).

I know that using cross-over cables with PXI systems works, since we do it all the time.

Rob

[Bob_Preis]

correction:

"...since it's only *necessary* when the..."

[Frenk]

Hello,

Thank you for the several responses so far.

Its the strangest thing. We have used two different crossed cables, that we know are alright.

I can initiate an ftp session, and I can connect to the PXI machine using MAX or LabVIEW. With ftp, I can get directory listings from the PXI, and I can put data onto the PXI, but I cannot transfer data files from the PXI machine (ftp just hangs there waiting, and there is no traffic).

I was confident that my own LabVIEW TCP code was alright since the machines talk over the LAN, and this ftp test confirms that something strange is happening.

As I mentioned previously, the subnet masks are the same, and the IPs differ only in the last octet.

Any further suggestions are much appreciated.
Thanks,
Fre
nk

[Bob_Preis]

Subnet masks were not mentioned previously.

I recommend you try TCPView. It's a useful program that will show you detailed listings of all TCP and UDP endpoints on your system, including the local and remote addresses and state of TCP connections. On Windows NT, 2000 and XP, TCPView also reports the name of the process that owns the endpoint.

For packet-level information, you could run Ethereal, which is a free network protocol analyzer for Unix and Windows.

[Anonymous]

Maybe you have already solved the problem...

Anyway, i suggest this:
When you are connecting on a network, TCP address numeric (i.e 32 bit,
normally split in four numbers) works fine.

If you use a direct connection, it is possible that this number is no
more recognized, and you must use the PC and PXI names as address.

Try this:
On TCP listen.VI (the only white icon in TCP palette) check what exit
as "remote address". If returned address is a PC name, instead of a
TCP address... maybe you have solved your problem.

Good luck.