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.