Help - Search - Members - Calendar
Full Version: Configuring 2 ethernet ports on a PC with Citect.
Forums.MrPLC.com > PLCs and Supporting Devices > General Topics - The Lounge > HMI & SCADA
rajsiyer
Hi Citect geeks,

Please take a look at this network. I can't get the configurations for ports, clusters, IO servers etc right . My IPC has 2 ethernet ports. My goal is to have the 4 Twido PLCs on one port, everything else on the other

Regards, best wishes, and thanks a million for looking in,

Raj S. Iyer
Crossbow
To have different devices on the different ports, you will need to use different IP addresses on each network.

As an example, my PLCs are 192.168.1.100 and above, and the PC network card is set to 192.168.1.2. My office network (for printers and Internet) is 192.168.2.100 and above. Then when you set up each network card, assign each an IP address on the network its connected to.

You will only need a default gateway set on the PC which routes on to get to a network or Internet connection. The PLC network does not need a default gateway set on the PC's network card.
paulengr
QUOTE (rajsiyer @ Oct 27 2009, 11:33 AM) *
Hi Citect geeks,

Please take a look at this network. I can't get the configurations for ports, clusters, IO servers etc right . My IPC has 2 ethernet ports. My goal is to have the 4 Twido PLCs on one port, everything else on the other

Regards, best wishes, and thanks a million for looking in,

Raj S. Iyer


Use subnetting. When you route a packet out of your PC, first it takes each Ethernet interface and looks at the mask. It does a bitwise AND with the mask and with the IP address of the outgoing packet. Then it compares this result with the bitwise AND of the mask and the IP address programmed into the interface card. It goes through them and looks for the one where the addresses match identically.

Otherwise, it will route to the nearest gateway (router) programmed into the interface. What it does with more than one gateway is somewhat undefined but usually it will just pick the first one (some systems are better than others in terms of how they pick the correct interface), and there are ways of programming the routing to force particular routes to happen. In practice usually a private LAN is just that and there's no reason to have to disambiguate between gateways (routers).

You can define say a "3 bit network" (just 8 addresses). The mask would be 255.255.255.248. The Twido PLC's can be anywhere within your existing or another address space so long as you have 8 consecutive addresses with the last 3 bits of 4th octet being zero for the first address. This makes it easy.

You can use ANY addresses but in practice, there are a few ones that are reserved specifically for this purpose, called "nonroutable" or "private" addresses. If you were just to pick any IP address, you might overlap some of the "public" addresses (on the internet) and render those internet sites inaccessible, so stick with the private IP addresses specified in RFC 1918. Those are 192.168.x.x (16 bits, or 65534 hosts), 10.x.x.x (24 bits, or 16,777,214 hosts), and 172.16.x.x through 172.31.x.x (12 bits or 4094 hosts). It's also a good idea to avoid all zeroes or all ones subnets because these are special and indicate "broadcast" packets.

Don't forget that by walling off your PLC's, you also limit yourself in terms of being able to do remote diagnostics/troubleshooting from engineering/maintenance workstations.
rajsiyer
Thanks.. to both Crossbow Paul..

Paul's answer is for keeps at our office where this issue of subnetting is not clearly understood amidst all engineers in our group.

However to revert to my problem... The IPs allocated are as follow.

The First Ethernet port has IP of 10.36.12.119, (given by client!) to which the Twidos are hooked at
10.36.12.120, 121,122 &..123. The Subnet masks are all 255.255.255.0

The IP address of the Second port on the PC is 10.36.12.85,to which M-340 and the 2 ODBC sources are hooked. M-340 has IP of 10.36.12.83, whereas the Access DSN lives at 10.36.3.160 & Oracle DSN at 10.36.18.20. Here too the mask on the Port's subnet is 255.255.255.0

In addition to sub-netting considerations as well explained by Paul, there is also the issue of configuring IO Servers , ports, boards and clusters in Citect. There are a few rules over here that I have not digested fully! During my last attempt. Citect had compiled without errors; but the moment the cable was attached to the 2nd port, ALL COMMS were disturbed. Again I have not understood which port Citect chooses at the time of SQL queries to the ODBC DSNs. Citect apart, it is possible to ping all destinations successfully from either port.

Thanks once again for your interest in helping out.

Best wishes for your success and happiness.

Raj S. Iyer

PdL
Although these articles cover redundant servers over multiple NIC, it might help you comprehend how Citect needs to be setup.
paulengr
Looks to me like you can make it work...

QUOTE (rajsiyer @ Oct 28 2009, 03:24 AM) *
Thanks.. to both Crossbow Paul..

Paul's answer is for keeps at our office where this issue of subnetting is not clearly understood amidst all engineers in our group.

However to revert to my problem... The IPs allocated are as follow.

The First Ethernet port has IP of 10.36.12.119, (given by client!) to which the Twidos are hooked at
10.36.12.120, 121,122 &..123. The Subnet masks are all 255.255.255.0

The IP address of the Second port on the PC is 10.36.12.85,to which M-340 and the 2 ODBC sources are hooked. M-340 has IP of 10.36.12.83, whereas the Access DSN lives at 10.36.3.160 & Oracle DSN at 10.36.18.20. Here too the mask on the Port's subnet is 255.255.255.0

In addition to sub-netting considerations as well explained by Paul, there is also the issue of configuring IO Servers , ports, boards and clusters in Citect. There are a few rules over here that I have not digested fully! During my last attempt. Citect had compiled without errors; but the moment the cable was attached to the 2nd port, ALL COMMS were disturbed. Again I have not understood which port Citect chooses at the time of SQL queries to the ODBC DSNs. Citect apart, it is possible to ping all destinations successfully from either port.

Thanks once again for your interest in helping out.

Best wishes for your success and happiness.

Raj S. Iyer


What's happening is that your subnet masks are BOTH valid. Either your PLC's or your servers are going to be inaccessible since the way you've defined things, the first network interface that matches will get picked. This simply isn't going to work. Second, you've bracketed the Twido PLC's with valid addresses so we can't create logically distinct IP address ranges.

OK, so lets throw away your existing subnet masks for a moment and think about this.

Converting 120 to binary is:
01111000

So...if we make a mask like this:
11111100

...everything will work fine. That value in decimal is 252.

The problem in this case is that you need a "hole" in your routing, since you have addresses both above and below the mask that you need to use. So let's contemplate one way of doing this.

We could set the subnet mask on the Twido PLC to "255.255.255.248", giving us 7 addresses. Set the IP address of the PC on that interface to "10.36.12.119" and everything works for that one. Then the second interface should include the router (gateway). You didn't specify your gateway (router) address. If it's say "10.36.12.1", you're in luck. Use a subnet mask as big as you can stand. In this case, that would be the first 64 addresses, or 11000000, giving a subnet mask of "255.255.255.192". You will need to change the second interface's IP address to something in the range of 10.36.12.1 - 10.36.12.63. This makes everything in the range of 10.36.12.1 - 10.36.12.63 directly accessible, and eliminates the overlapping subnet problem. If you leave the original address of 10.36.12.85, then the subnet will be from 10.36.12.64 to 10.36.12.127, which again causes the overlap problem and doesn't accomplish anything at all. You might be able to get away with a smaller subnet but whatever you do, you must end up with the address of your router (gateway) in the same subnet as your PC or nothing will work right.

This looks like you "broke" the connection to 10.36.12.83. But, this is not the case. All that happens is that the packet gets sent to the router instead of directly over the LAN. The router sees the packet and the network correctly and just resends the packet right back out the same port. The packet then goes to 10.36.12.83. Since 10.36.12.83 has a "correct" subnet of 255.255.255.0, it knows that the PC is in fact on the same subnet and will route any return packets directly to the dual-homed PC rather then bouncing the packet back through the router. You will be loading up the router with traffic that doesn't really need to be routed but at least everything works. The best method would be to assign new IP addresses on a different subnet to the Twido PLC's and change all the settings as needed to point to the new subnet so that you don't have an overlapping subnet problem. Setting them to 192.168.1.x with a subnet mask of "255.255.255.0" would be the best solution.

You can also manually view (and even change) the routing table that your PC is using. Bring up a command prompt; hold down the left "Windows" key and press "R" for "run", and then type "cmd" and press enter. Now type "ipconfig /all" to view your interface table (this is much more reliable than using the Windows graphical interface which is sometimes wrong), and type "route print" to show the routing table. "Route add" and "route delete" (google them) can be used to modify the routing table itself. Note that Windows reads the routing table top to bottom. If you use the configuration you mentioned above that didn't work, looking at the routing table should provide you a clue as to why it didn't work.
rajsiyer
Whew....
Thanks to Pdl, and Paul once again. I read, re-read what you both have sent me. Have to wait for an opportune moment though to interrupt the production and change the IPs of the PLCs. Will keep you all posted.

Raj S. Iyer
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.