remote programming ns screen over cel based internet

[professor_jonny 1]

Hi there I have a ctek 4400 skyrouter celphone based internet and have set up a dynamic dns server and can log in find the ip and type it into a fins gateway and remote program a cj2m plc, but i cant program the ns screen over the same link either as direct or passing through the onsite plc. the ip adresses of the router is 192.168.250.254 and the plc is 192.168.250.1 and the screen is 192.168.250.2 i have forwarded port 9600 to the ip adress of the plc and port 80 to the sceen for the web page. the managment port of the router is set to 8080 to not cause issuies with port 80 of the screen. i have set the default gateway in cx designer as the ip adress of the router and have forwarded inbound port 9680 to 9600 of the screens ip address as i did with the plc but nada. i can ping both ports of the screen and plc and i get replys but the screen will not program but onsite it works perfectly. so i guess there is an issue with packet sizes for data for the screen over the net or something? would any one have a clue how to fix this? if i type in an incorect ip adress or node it says it cant find the screen in 2 seconds flat but if i type in the corect programming details it hangs atempting for a min or so then quits with error and changing the time out will not effect the status so i guess it is a network related problem or an endless problem of waiting for buffer to fill somewhere before passing on the data. is there some way i can upload the program to the screen using the onsite mem card by sending the information to the card via the net then doing an onsite update? or possibly pop the mem card in the plc and use the memory editor to transfer an image of the memory card using the memory edit function then pop it in the screen to update it ? cheers pj

[PMCR 66]

I can explain what is happening. Omron HMIs and PLC CPUs (excluding the Sysmac NJ) don't support Ethernet on the CPU. Ethernet is another module or an architecturally different part of the device, such as on the NS. When the command is delivered to the CPU, it is delivered by FINS addressing only, and the IP information has been stripped off at the Ethernet card of the HMI or PLC. So, when the NS or PLC goes to respond to an Ethernet command, it relies on the Ethernet module (or Ethernet portion of the NS) to construct the IP to send the response back to. In the PLC Ethernet cards, such as ETN21 or EIP21, the card has 'Auto Dynamic' FINS to IP conversion, which allows the Ethernet module to maintain a dynamic list of IP Addresses, and the FINS Node numbers associated with those IP Addresses. So, when your PC sends a command to an ETN21 card on a CJ, the ETN21 captures the FINS Node Number that your PC reports itself to be, and the IP Address of your PC. ETN01, ETN11, and NS Ethernet cards do not support the 'Dynamic' part of the FINS to IP conversion, they only support 'Auto Static' FINS to IP conversion. That means that the NS will respond only to devices on it's own subnet. What actually happens is the NS responds to an IP Address constructed of its own first 3 octets, and then creates the last octet from the FINS Node Number that your PC reported itself as. An example: Your PC is 1.2.3.4, and the NS is 192.168.1.100. If your PC sends a command to the NS (routed across the Internet), the NS will send the response to 192.168.1.4, because your PC will have reported its own last octet as its node number. Here is the only solution: If you are always programming from a location with a static WAN IP Address (your home, office, etc), you can program the NS with a list of FINS Node Numbers and IP Addresses. You would list all the devices (PLCs, PCs, etc) that the NS needs to communicate with. This is done in the Conversion Table in CX Designer. so, for example. NS: 192.168.250.2 PLC: 192.168.250.1 WAN IP Address of the router in your office: 68.84.215.203 (I just make that up) You would program in the NS: Node 1, 192.168.250.1 Node 100, 68.84.215.203 Then when you connect to the NS, you specify the IP Address of the router at the remove facility, and you uncheck the 'auto detect' box for the source node number of the PC, and specify 100. That way, when the NS goes to respond, it sends the response back to your local router, and since this is a proper response to a command, it is sent back to your PC without Port Forwarding needed in your router.

[Jay Anthony 118]

Awesome explanation as usual from PMCR.