CS1W-ETN21 / CS1G-CPU42H / SCADA IP routing anomoly

[Charlie_A 0]

One of the setup has CS1G-CPU42H and a CS1W-ETN21 module. The IP address of the ethernet module is 10.160.5.6 with a subnet of 255.255.255.0 The CX programming computers are on the same subnet with IP addresses of 10.160.5.25 and 10.160.5.61 The computers with the SCADA packages (10.160.6.72 and 10.160.6.73) hits the PLC through a router which has an address of 10.160.5.254 Depending on which SCADA computer is run, only one will be trying to access the PLC at a given moment. The IP Router Table in the ETN21 setup is set as follows: 10.160.5.25 10.160.5.25 10.160.5.61 10.160.5.61 10.160.6.72 10.160.5.254 10.160.6.73 10.160.5.254 The anomoly is the programming computers. I can connect to the PLC through CX with 10.160.5.25 but not 10.160.5.61 I realize that if the programming computers are on the same subnet you do not need a routing table. The reason for that being there is that when the ip routing table for the SCADA computer was put in, the programming computers were no longer able to connect with the PLC. Once I put the routing table for the Programming computers via serial connection, the one programming computer was able to talk to the PLC. The programming computers are exact VM clones with except with different software serial numbers. Can anyone suggest where the fault lies?

[lostcontrol 23]

Out of left field, but does the Workstation Node number = the last octet of the IP address of the PC?

[Charlie_A 0]

Can you identify which sub menu you got in to in order to get to that screen? I do not see it within the IO TABLE CS1w-ETN21 menu

[rquirch 0]

some insight... when working with etn21's i have found that if the comms port eg "udp9600" is busy doing comms with a scada, cx programmer will time out and not be able to go online, and viceversa... if connected with cx-programmer via ethernet an hmi will not be able to get data trough that same etn card until you disconnect your cx programmer. this was at very high speed scan rates i dont know if the problem continues with slower scan times... the other thing would be to route the whole network instead of individual entries, ex: 10.160.6.0 trough 10.160.5.254 i dont think you need the static entries for the: 10.160.5.25 10.160.5.25 10.160.5.61 10.160.5.61

[lostcontrol 23]

We have found this as well, a solution is to use FINS/Tcp instead.

[PMCR 66]

The idea of the IP router table is to build 1 or more 'gateways' to IP segments that are not local. The best way to do this on ETN21 modules of firmware 1.3 or higher (1.5 is current) is to set 0.0.0.0 10.160.5.254. This will force all traffic that is not being returned to the local network to go through the router. On firmware versions before 1.3 of the ETN21, 0.0.0.0 was not allowed, so you did 10.160.6.0 10.160.5.254. In either case, local IP addresses do not belong in the IP router table. Multiple PCs (SCADA, CX Programmer, etc) should not be a problem for an ETN21. On the setup of the ETN21, what 'Conversion' method are you using? Auto-Dynamic, Auto-Static, etc.

[Charlie_A 0]

I am using Auto-Dynamic I will see if firmware upgrade is possible on this unit on Monday and let you know how it pans out. Can you think of a reason why the one programming computer can connect with the PLC but not the other? Thank you for your help. Edited 15 Jan 2010 by Charlie_A

[Charlie_A 0]

The workstation number is set to auto detect.

[PMCR 66]

Omron modules are typically not 'field upgrade' capable. Even if the firmware is older, there is no need to upgrade. You would simply enter the IP Router info differently. If you can put together the following information, I can probably nail down the issue: 1. Screen shots of the setup of the ETN21 from CX Programmer / IO Table utility 2. Screen shot of CX Programmer / Network / Setup / Driver tab for the 2 PCs talking to the PLC. (This is where the IP address of the PLC is set).

[lostcontrol 23]

This does not always mean it is correct! I think I actually put you crook with the screen shot, but the comment was correct. In the box that says auto-detect, have you tried changing it to not be auto-detect, and setting it to the IP address of the PC that is on the PLC network? Do the PC's have dual NIC's? This can also be an issue. Also, it is worth posting the screenshots of the info that PMCR has requested, you'll be impressed with the results!! Edited 16 Jan 2010 by lostcontrol

[Charlie_A 0]

The two programming machines are accessing the plant file server with the CX program. The drivertab screenshot that wasn't posted has the .61 for the last octet. Edited 18 Jan 2010 by Charlie_A

[PMCR 66]

Charlie Great information. I think the IP router table is the issue. Lets get a look at the version of the ETN module. 1. Open the IO table in CX Programmer. 2. Upload the IO table if you do not see the Ethernet module listed. 3. Right click on the ETN21, and select Unit Manufacturing Information. 4. Look at the Unit Ver (the last item) as shown below. If this is 1.3, 1.4, or 1.5 then set the IP router table as shown. This will send all traffic not bound for the local network through the router. If the Unit Version is before 1.3, then setup as shown below. This will send all traffic bound for 10.160.6.* through the router.

[Charlie_A 0]

It was version 1.4. I actually tried entering that entry along with the other entries I've made, but it didn't work. I've tried just entering the suggested routing entry and everything works beautifully. Thank you for your assistance.

[Jay Anthony 118]

PMCR comes through again!