Program changes and monitoring via internet

[mjrx 1]

After several projects with Q series, I have always been able to make minor changes over the internet. However, and I'm wondering if anyone else has thoughts or experience with this, I have never been able to communicate over the internet with a high degree of reliability - connections always seem kind of unstable and while monitoring the connection will eventually timeout. Often several attempts to invoke the monitor are needed before it will "catch" and will timeout soon after connection is established. Is this just to be expected when dealing with internet traffic?

[kaare_t 155]

What kind of equipment to you use to connect over the internet, on both sides? Do you use VPN connections? Wireless connections? GPRS/3G connections?

[Mitsu 2]

Might be interesting to say what software you are using. I've been using VPN (and modem) a lot in combination with Gx Developer and Gx works and never had any connection problems. In fact, most plc program updates (online changes or installing complete programs, monitoring and such) are all done with VPN (or modem for customers who don't offer VPN access) nowadays. However, the connections are mostly through cable. Wireless connections are definately less stable and depend on coverage of signal in regions/countries (for example 3G coverage can be a problem in our country in certain regions). In that case, connection dropouts do occur. Edited 22 Dec 2010 by Mitsu

[mjrx 1]

Most of my clients have cable internet or DSL connections. I am using GX Developer v8.89. I have a router/switch connected to the PLC & HMI. I have port forwarding on in the router forwarding through to the ports I need (6000, 6001 in the E1101 HMI's, and I think 5000 or whatever the default is for the PLC) and the customer has a static IP. So in my GX Dev transfer setup, I just put that static IP in and it forwards through to the PLC. It always seems to work, but it is not very reliable, and if course some connections are better than others. Should I be taking a different approach to this, rather than the port forwarding approach? Router is a Linksys, either a BEFSX41 or the same with a wireless access point. Both work fine when I am in the plant on their LAN, either wired or wireless, but when I'm offsite not so good.

[kaare_t 155]

When you are off-site, do you use a cable connection or do you use a wireless connection of some kind when you "call" the remote site?? We mostly use VPN connections to remote sites, but there should be no problem with Port Forwarding either....

[mjrx 1]

I use a cable connection (Comcast) to call my remote sites. I have tried with other computers at different sites, some with cable, some with DSL. The remote sites are usually cable or DSL. A few remotes use Verizon wireless and this seems to work about the same as the hardwire connections, not really better or worse. I have tried both UDP and TCP in the GX Dev transfer setup.

[kaare_t 155]

I'm really not sure what could cause the problems, again we normally use VPN connections instead of port forwarding. You could try and change one of the routers at one of your end points to a more business router (like a Cisco/Zyxel/Netgear) or something. Maybe the problem is the remote router?? One thing though; have you set up the Gateway address correct in the PLC's?? The gateway address should point to your router.

[mjrx 1]

Where do you enter the gateway address? The only thing I ever change is in the "Operational Settings" where I enter the IP address, check "Enable Write at RUN Time", Send frame setting to "Ethernet(2.0)", Communication data code to "Binary code", Initial timing to "Do not wait for OPEN" and TCP Existence to "Use the KeepAlive". Other than the IP address, most of these are defaults, I don't usually change them. If I needed to set something up like a gateway address, I would think it wouldn't work at all. Thanks.

[kaare_t 155]

First of all you should set the flag "Always wait for open" to true. Secondly, the gateway parameters can be found under "Router Relay Parameters", where you enter the default router IP address if you use a Qn series CPU. If you use a QnU series CPU you can find the setting under "Built-in Ethernet port".

[mjrx 1]

Thanks for the tips. How would it be working without entering anything in router IP field?

[kaare_t 155]

That's the "strange" thing about Mitsubishi PLC's; they sometimes seem to work without anything in the router IP field, however most other equipment requires the router IP to be able to work at all when it comes to routing/forwarding IP communication via a router. This could very well be the issues you are facing. The router IP field tells the ethernet card where to send packets which it "don't know where came from". And in your case the original IP address is an outside address (not a LAN address). Therefore, in theory, the ethernet card must know where to send packets.... But as mentioned above, I've also discovered that Mitsubishi PLC's sometimes work even if you don't have anything in the router IP field, even if you are communicating via a router.

[mjrx 1]

I would have thought through forwarding in the router the IP address would be known to the ethernet card - any access from the outside to the WAN static IP address is redirected to a LAN side address, i.e. any inquire to 77.321.44.9 port 5000 would route through to 192.168.1.100:5000, so the Q PLC ethernet card really thinks it is just being accesed from the LAN. I am just throwing that out there, I'm still having problems with it. Thanks.

[kaare_t 155]

It's not that easy, the original IP address is still kept in the IP packet. You always have a gateway address in your PC when you wish to connect to the internet right? But your router performs NAT on all incoming/outgoing messages right? In your theory you say that you can drop the router address because all the PC's communicate with the router which has an inside address (since the router performs NAT'ing your PC speaks with the router and not the internet). This is however not the case! Therefore you should set up the gateway/router address in your PLC's