Problem TCP IP communication

[jbhee]

Hi,

I have a network card (D-Link DFE-580TX) with 4 Ethernet Ports (IP1, IP2, IP3, IP4), each port are connected with four different clients.

Each client are the same IP adresse, is it possible to open a Modbus communication with only one client to indicated the IP host and the IP client ?

Thank you for your response,

[Mark Yedinak]

If I understand you correctly you are saying that you have four devices connected to the network each having the same IP address. If this is the case this is an illegal network configuration and it will cause you problems. IP addresses must be unique on a network. If my understanding is incorrect than please clarify so that I can provide a better informed answer.

[jbhee]

Thank for your answer, in fact I have a network card with 4 Ethernet ports with IP1, IP2, IP3 and IP4. On each port I connect products which have a fixed and unchanged IP, this IP is the same for each product. So I have 4 different networks (IP1 <-> IP, IP2 <-> IP, IP3 <-> IP, IP4 <-> IP) and I must open a TCP communication with each product and the PC. I have used the VI TCP Open Connection but I can put anly the client IP and I don't put the host IP (IP, IP2, IP3 or IP4), so I don't know which product is. Which is code I can use to put the IP client and the IP host to create a TCP connection ?

Sorry for my poor english, thank for you answer,

[Dan DeFriese]

QUOTE (jbhee @ Feb 4 2009, 11:11 AM)

Thank for your answer, in fact I have a network card with 4 Ethernet ports with IP1, IP2, IP3 and IP4. On each port I connect products which have a fixed and unchanged IP, this IP is the same for each product. So I have 4 different networks (IP1 <-> IP, IP2 <-> IP, IP3 <-> IP, IP4 <-> IP) and I must open a TCP communication with each product and the PC. I have used the VI TCP Open Connection but I can put anly the client IP and I don't put the host IP (IP, IP2, IP3 or IP4), so I don't know which product is. Which is code I can use to put the IP client and the IP host to create a TCP connection ?

I don't think this will work in Windows... Not only do the network interfaces have to have a different IP, they have to have different subnet masks, also... Which will result in 3 of your units being blocked.

1) My first approach (if possible) would be to set the network config (IP and Subnet) of your products at power on using some digital inputs based on the fixture so that they are within the subnet of their respective network cards.

2) If option 1) is not possible then you may want to look into WinPCAP and doing your communication as raw socket. -> Not super difficult if you don't have to have TCP connection, but could be very time consuming in any case.

[Mark Smith]

QUOTE (jbhee @ Feb 4 2009, 10:11 AM)

Thank for your answer, in fact I have a network card with 4 Ethernet ports with IP1, IP2, IP3 and IP4. On each port I connect products which have a fixed and unchanged IP, this IP is the same for each product. So I have 4 different networks (IP1 <-> IP, IP2 <-> IP, IP3 <-> IP, IP4 <-> IP) and I must open a TCP communication with each product and the PC. I have used the VI TCP Open Connection but I can put anly the client IP and I don't put the host IP (IP, IP2, IP3 or IP4), so I don't know which product is. Which is code I can use to put the IP client and the IP host to create a TCP connection ?

Sorry for my poor english, thank for you answer,

The short answer is "you cannot" - LabVIEW does not expose an interface to allow selection of a specific interface for outbound TCP/IP packets. And that's because the OS does the selection. Here's a little more info

http://digital.ni.com/public.nsf/websearch...5E?OpenDocument

http://support.microsoft.com/kb/175396

It appears you may be able to do some command line programming to set temporary routes

http://www.tech-recipes.com/rx/478/nt2000x...-routing-table/

and set the route "if" parameter to force a specific interface

[OlivierL]

There is an easy way to open a TCP connection using the TCP interface of your choice. I can't find the code I wrote in the past using this technique but I'm 98% certain that this is right though:

Use "VISA Open" and specify the Ressource Name to be: TCPIP SOCKET TCPIP[board]::host address::port::SOCKET TCP/IP Socket

[board] allows you to select which interface you wish to use. You can then talk to the device using regular VISA VIs. For more information, look up "VISA Resource Name Control" in LabVIEW help files.

Hope this helps.

Olivier

[Mark Smith]

QUOTE (OlivierL @ Feb 5 2009, 10:45 AM)

There is an easy way to open a TCP connection using the TCP interface of your choice. I can't find the code I wrote in the past using this technique but I'm 98% certain that this is right though:

Use "VISA Open" and specify the Ressource Name to be: TCPIP SOCKET TCPIP[board]::host address::port::SOCKET TCP/IP Socket

[board] allows you to select which interface you wish to use. You can then talk to the device using regular VISA VIs. For more information, look up "VISA Resource Name Control" in LabVIEW help files.

Hope this helps.

Olivier

That is very interesting! I've never had occasion to use TCP/IP for instrument communication, so that one went right past me. Do you know of any examples using VISA that implement a client/server? Not that I have a real need, I'm just curious.

Thanks,

Mark

[Mark Yedinak]

QUOTE (OlivierL @ Feb 5 2009, 11:45 AM)

There is an easy way to open a TCP connection using the TCP interface of your choice. I can't find the code I wrote in the past using this technique but I'm 98% certain that this is right though:

Use "VISA Open" and specify the Ressource Name to be: TCPIP SOCKET TCPIP[board]::host address::port::SOCKET TCP/IP Socket

[board] allows you to select which interface you wish to use. You can then talk to the device using regular VISA VIs. For more information, look up "VISA Resource Name Control" in LabVIEW help files.

Hope this helps.

Olivier

This is useful information but it is still a very bad idea to give the same IP address to all of the clients. This can cause some major problems on your network. Duplicate IP address can lead to routers and switches on the network having bad routes and can create data loops and circular routes within the network. Worst case this can bring a network down. If the IP addresses of these clients can be seen by network I would strongly recommend against using duplicate IP addresses. From a network perspective you are asking for trouble.

[Phillip Brooks]

QUOTE (Mark Yedinak @ Feb 5 2009, 01:45 PM)

This is useful information but it is still a very bad idea to give the same IP address to all of the clients. This can cause some major problems on your network. Duplicate IP address can lead to routers and switches on the network having bad routes and can create data loops and circular routes within the network. Worst case this can bring a network down. If the IP addresses of these clients can be seen by network I would strongly recommend against using duplicate IP addresses. From a network perspective you are asking for trouble.

I agree with everything you've mentioned, but we don't know how the UUT(s) are being used.

One use case would be that the OP is performing final testing on modbus equipment in a manufacturing environment and wants to perform final test on several units in parallel from one LabVIEW station. Each UUT would be at a factory default address (e.g. 192.9.100.1) and the test station would have four distinct IP addresses for the 4 ports on the network card.

[Mark Smith]

QUOTE (Mark Yedinak @ Feb 5 2009, 11:45 AM)

This is useful information but it is still a very bad idea to give the same IP address to all of the clients. This can cause some major problems on your network. Duplicate IP address can lead to routers and switches on the network having bad routes and can create data loops and circular routes within the network. Worst case this can bring a network down. If the IP addresses of these clients can be seen by network I would strongly recommend against using duplicate IP addresses. From a network perspective you are asking for trouble.

Mark,

I'm gonna guess that you and I are working from the same paradigm where we see TCP/IP and client and we start thinking about servers and distributed apps and networks. But I think that this problem is just one of local instrument control where a Ethernet and a NIC can replace a GPIB cable and card. So this is like having to address four instruments that all have the same GPIB primary address that can't be changed (I know that doesn't make any sense, but then again I can't imagine an Ethernet-enabled instrument where the IP address can't be changed, but that's apparently the case) by addressing four separate GPIB controllers so the VISA string might look like

GPIB0::2

GPIB1::2

and so on.

But I'm extrapolating here, since we haven't heard back from jbhee on this!

Mark

Edit: also what Phillip said (he got that in before I posted)

[Mark Yedinak]

QUOTE (mesmith @ Feb 5 2009, 01:00 PM)

Mark,

I'm gonna guess that you and I are working from the same paradigm where we see TCP/IP and client and we start thinking about servers and distributed apps and networks. But I think that this problem is just one of local instrument control where a Ethernet and a NIC can replace a GPIB cable and card. So this is like having to address four instruments that all have the same GPIB primary address that can't be changed (I know that doesn't make any sense, but then again I can't imagine an Ethernet-enabled instrument where the IP address can't be changed, but that's apparently the case) by addressing four separate GPIB controllers so the VISA string might look like

GPIB0::2

GPIB1::2

and so on.

But I'm extrapolating here, since we haven't heard back from jbhee on this!

Mark

Edit: also what Phillip said (he got that in before I posted)

You might be write but I can't imagine anyone creating a networked device that isn't intended to sit on a real network. My entire professional career has been in the network world and the thought of duplicate IP addresses makes me cringe. You may be right and this is intended to be the equivalent of a hard wire replacement but I don't see the logic in anyone doing this. The beauty of a network is that you can place equipment anywhere and be able to communicate with it. Once you are on the network you should play by the rules. Anyway, that is the network guy in me talking.

[Mark Smith]

QUOTE (Mark Yedinak @ Feb 5 2009, 12:13 PM)

You might be write but I can't imagine anyone creating a networked device that isn't intended to sit on a real network. My entire professional career has been in the network world and the thought of duplicate IP addresses makes me cringe. You may be right and this is intended to be the equivalent of a hard wire replacement but I don't see the logic in anyone doing this. The beauty of a network is that you can place equipment anywhere and be able to communicate with it. Once you are on the network you should play by the rules. Anyway, that is the network guy in me talking.

I think the reason instrument manufacturers do this is cost and performance. It's really inexpensive compared to GPIB (I just did a quick google and found a network interface chip for <$5 and a GPIB chip for around $30) and all personal computers come equipped with a NIC (a GPIB Interface Card could set you back a few hundred dollars). Also, 20 feet of Cat 5 cable w/connectors is at most a $10 item and a 20 foot GPIB is more like $100. So this has become the "new serial" port for some vendors (of course, USB is really the "new serial" and some vendors use that). So these aren't really "network" devices in the more conventional sense (someone from across the country connecting to my Tek Scope is kind of pointless) , they're just devices leveraging cheap communication technology.

Mark

[Rolf Kalbermatter]

QUOTE (mesmith @ Feb 5 2009, 02:43 PM)

I think the reason instrument manufacturers do this is cost and performance. It's really inexpensive compared to GPIB (I just did a quick google and found a network interface chip for <$5 and a GPIB chip for around $30) and all personal computers come equipped with a NIC (a GPIB Interface Card could set you back a few hundred dollars). Also, 20 feet of Cat 5 cable w/connectors is at most a $10 item and a 20 foot GPIB is more like $100. So this has become the "new serial" port for some vendors (of course, USB is really the "new serial" and some vendors use that). So these aren't really "network" devices in the more conventional sense (someone from across the country connecting to my Tek Scope is kind of pointless) , they're just devices leveraging cheap communication technology.

The chip is not everything. You can easily create a GPIB driver that works reasonably on an 8 Bit CPU. Getting a TCP/IP stack to run properly on such resource constrained hardware is quite a different challenge. That said the embedded controller nowadays even for very simple devices get to a level that has more processing power than a complete mainframe from 30 years ago and is quite likely a 32 bit CPU core too. Also the knowledge about how to implement TCP/IP (open source implementations all over) is probably getting to a level were it is easier to dig into that than getting the somehow archane and not very easy to tackle task to control a GPIB controller to work.

But that is certainly a recent development. Even a few years back adding a TCP/IP connection to a device was certainly more expensive than doing that with a GPIB interface even for manufacturers that had already quite some experience with TCP/IP interfaces in their devices.

Rolf Kalbermatter