Slow connection to compactlogix

Ewon Support eWON Cosy
#1

I’m have extremely slow connection issues to our CompactLogix controllers via the eWon cosy 131, running FW14.0s02

I’ve tried changing to TCP and have seen no noticeable difference.

Our customers are place around the globe and have this issue.

I’ve setup a test rig up in our UK office. We have a fibre connection in the UK with plenty of bandwidth. The rig is about 5 metres away from me and I’m using my laptop with eCatcher on.

The ewon and the PLC is on the same subnet, and configure in the LAN devices & Firewall.
Im using an ethernet connection in RSLinx , and have my PLC ip Map setup.
( I have also tried FactoryTalk Linx as the communication)

If I monitor the bandwidth of the Talk2m VPN connection when connected to the VPN and doing the following,

  1. using the webpage, I can see I nearly hit 1Mbs and the web pages are reasonably snappy of the eWon 131.
    Using the webpage and visit the IP address of the PLC, the webpages are snappy and I can also hit 1Mbs.

  2. update the firmware using eBuddy, I hit 1.5Mbs and the firmware transfer is quick.

  3. using PLC, compactlogix 5380 CPU , the connection speed either up or down never goes above 64kbs , that’s kilo bits , not bytes !
    With 3) , the connection to the PLC is pretty much unusable, and I can’t trust it in production status.

Any help would be appreciated as currently I can’t use these units to support our customers.

#2

What kind of internet connection is the device using? Ethernet, Wifi, 3G/4G?

#5

Tim
It’s using hard wire Ethernet connection.
The internet service to the unit is fibre and is perfectly fine.

When remote browsing the plc webpage , my traffic monitor through the VPN shows I’m peeking at 1Mbs , but when I connect studio 5000 , it takes a long time , say 45 seconds to achieve an online status , and very slow performance.
Typical throughput when monitoring the VPN bandwidth never peaks above 60kbps , kilo bits , hence its super slow.

I’ve tried the TCP port. The logs show I’m connected via TCP to verify.
It would seem that just communication to the PLC is horrid. I will hook up a panel view 7 on Monday and see what the throughput to that is to see if it’s both units.
Regards
Steve

#6

Hi Steve,

One of my colleagues was suggesting this to find out if it’s an issue with the size of the packets being sent.

As an example can you try this with 1800 bytes:
ping 192.168.0.28 -t -l 1800"

-Tim

#7

Morning Tim
No problem with the PLC receiving 1800 bytes, or even greater.

I’m seeing some dropped packets, ( not many ) using 32 bytes, pinging the eWon unit at times.
My response is average 85ms, peaking at times up to 300ms.

I will hook up a Panelview shortly and see what response I get from that.

Regards
Steve

#9

Not had chance to put a Panelview on yet, however I put another Laptop on the eWon end, and transferred a file from my Laptop using the VPN.

Speeds, although not great I had peeking at 1.5Mbs , the overall speed is not consistent, and jumps around a lot, however average throughput is much faster when going Laptop – VPN – Laptop

Back to the PLC, I monitored the hard wired connection going directly from my Laptop – switch – PLC, speeds peaked a 3Mbs, and on average 10x the speed when connected through the VPN.

Tried back using the Laptop – VPN – PLC and again , woeful speeds.

As proved, I can get some speed when using 2 laptops , therefore assume the eWon connection is fine,

Looks like some throttling or something getting slowed down with the PLC packet transfer on this PLC.

Its a 5069-L306ER model ( 5380 series )

#10

When you get the chance, could you try and run that section of the command prompt above?

Can you also verify that you’re using a TCP connection through eCatcher as well as through the webpage of the device?

image

image
image837×559 20.1 KB

-Tim

#11

Tim
I did not have the ecatcher set to TCP, however when I do it wont connect.
My openVPN log is below

Mon Nov 02 16:43:05 2020 OpenVPN 2.3.11 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Jan 31 2019
Mon Nov 02 16:43:05 2020 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Nov 02 16:43:05 2020 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.09
Mon Nov 02 16:43:05 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.146.54.166:3418
Mon Nov 02 16:43:05 2020 Need hold release from management interface, waiting…
Mon Nov 02 16:43:05 2020 MANAGEMENT: Client connected from [AF_INET]127.146.54.166:3418
Mon Nov 02 16:43:05 2020 MANAGEMENT: CMD ‘state on’
Mon Nov 02 16:43:05 2020 MANAGEMENT: CMD ‘log on’
Mon Nov 02 16:43:05 2020 MANAGEMENT: CMD ‘hold release’
Mon Nov 02 16:43:05 2020 Socket Buffers: R=[65536->65536] S=[65536->65536]
Mon Nov 02 16:43:05 2020 MANAGEMENT: >STATE:1604335385,RESOLVE,
Mon Nov 02 16:43:05 2020 Attempting to establish TCP connection with [AF_INET]87.98.174.164:443 [nonblock]
Mon Nov 02 16:43:05 2020 MANAGEMENT: >STATE:1604335385,TCP_CONNECT,
Mon Nov 02 16:43:06 2020 TCP connection established with [AF_INET]87.98.174.164:443
Mon Nov 02 16:43:06 2020 TCPv4_CLIENT link local: [undef]
Mon Nov 02 16:43:06 2020 TCPv4_CLIENT link remote: [AF_INET]87.98.174.164:443
Mon Nov 02 16:43:06 2020 MANAGEMENT: >STATE:1604335386,WAIT,
Mon Nov 02 16:43:06 2020 Connection reset, restarting [-1]
Mon Nov 02 16:43:06 2020 SIGUSR1[soft,connection-reset] received, process restarting
Mon Nov 02 16:43:06 2020 MANAGEMENT: >STATE:1604335386,RECONNECTING,connection-reset,

#12

Could you try connecting to a hotspot on your phone and see if you’re able to make the TCP connection after that?

#13

Hi Steve,

Can just wanted to see if you had an update on this?

-Tim