V130 problem with Ethernet

[Rick_PN]

Hi,
(Edit:  For convenience, the final solution of this issue is at the end of this first post)

I am having problems with ethernet connection on V130 (33-R34) OS 4.4 (31) with V100-17-ET2 ethernet module. Problem is that sometimes (mostly random) connection somehow breaks and I am no longer able to communicate with V130 (using Visilogic) via Ethernet. To be more precise: Ethernet connection sometimes breaks after downloading the project (after RUN command is send). I don't have the data on how the Ethernet behaves when PLC is running for a long time - this project is new and I have been able to test it only for some days. But as for now I have never get disconnection while running "Online Test" mode or while downloading the project (just right after downloading).

But while programing V130 and testing the project/program (for the past week or so) I noticed that after downloading the project sometimes Ethernet would work right away but other times wont. This even happens if there are no changes to Power-up setup of Ethernet.

There is no difference If I Burn the project or just Download it. It happens when the PLC restarts and it’s about let’s say 80% chance that it will work and 20% that it won’t. Which is really frustrating because I cannot rely on this to be able to program or control the PLC remotely.

What usually works to reestablish the connection is to power off and back on the PLC (not great) OR to just un-plug the Ethernet cable, wait a few sec and plug it back in. Sometimes I need to wait ~2sec before plugging it back in and sometimes ~5sec for the connection to work again.

My initialization process is presented in attached file. I had shuffled the “PLC NAME”, “TCP/IP” etc. blocks in all combinations and nothing works.

 Maybe it’s a network thing (but if I recall it correctly I had similar problems when I started using V130 and learn how to use it on my home network, but I shrugged it off as “beginner problems. Nonetheless I added PLC IP and MAC on my DHCP list (as static address assignment), but this didn’t resolve the issue.

 

How can I fix this issue?

Any help appreciated.

 

EDIT: Parameters of above presented blocks:

It's pretty much the "default".
Physically the other end of Ethernet connection is a router (build-in switch), right now I am using Visilogic (via wireless) to connect to PLC and sometimes Remote Access.

 

EDIT2 (22.10.2018): I apologize for delayed responses but my replies are moderated and need to be approved by a moderator.

 

Solution

EDIT3 (19.11.2018): After hours of testing, downloading, changing cables, making cables I decided to try more routers. As is often the case, the problem was "easy to solve". It appears some routers aren't friendly with PLCs network card. I tested 4 routers: ASUS RT-AC1200G+, Fritz!Box WLAN 7360, Buffalo G54 and LevelOne (only a switch). All of these devices don't cause  any problems while only PCs, Printers, TVs are involved. Everything works as it's suppose to.

But, three of them: WLAN 7360, Buffalo G54 and LevelOne are not compatible with V130 PLC. If I connect V130 to any of those I get problems that are described here in this topic.

LevelOne, Buffalo G54 were my old devices that is why I was having problems with ethernet when I started learning with V130. ASUS is my latest upgrade so I decided to bring all of these 3 devices to the site where V130 is installed and test all of them (WLAN 7360 was already on the site).

It is strange that 3 out of 4 devices didn't work. Maybe there is a problem with some old devices or sth. Newer device (ASUS router) worked perfectly, right away with no modifications to the program.

Debugging this kind of problem is tedious because one does not simply have 4+ routers to test with on remote sites. I am pretty sure this is a solution because I didn't get any error in one week of testing.

Thank you all for your guidelines and solutions.

[Flex727]

We need to see inside those function blocks, what protocol you're using, and what is on the other end of the Ethernet connection.

Two other (irrelevant) issues with that ladder: you don't need to explicitly "SET" SB 168 with SB 2 when you have assigned SET as the Power-Up value. Also, similar thing with SI 104 - you assign a Power-Up of 50 then also store 100 into it with SB 2. This isn't your problem, but it makes no sense to me.

6 hours ago, Rick_PN said:

My initialization process is presented in attached file. I had shuffled the “PLC NAME”, “TCP/IP” etc. blocks in all combinations and nothing works.

The order of those blocks makes no difference.

[Rick_PN]

1 hour ago, Flex727 said:

We need to see inside those function blocks, what protocol you're using, and what is on the other end of the Ethernet connection.

Two other (irrelevant) issues with that ladder: you don't need to explicitly "SET" SB 168 with SB 2 when you have assigned SET as the Power-Up value. Also, similar thing with SI 104 - you assign a Power-Up of 50 then also store 100 into it with SB 2. This isn't your problem, but it makes no sense to me.

The order of those blocks makes no difference.

Thank you for your answer.

I added startup block parameters in the main post and added PLC OS version - 4.4 (31).

I am aware of all your points. I am using this blocks to test some performance (SI104) so they are there for this "debuging". When you get this random incoherent disconnects anything is a suspect. In some "official" example files SB168 is set like this (in some isn't) and clearly it does not solve my issue. Thanks for the tips anyway!

Best Regards!

[Flex727]

5 hours ago, Flex727 said:

We need to see inside those function blocks, what protocol you're using, and what is on the other end of the Ethernet connection.

Are you going to answer this?

[Joe Tauser]

As Flex says, you've already got SB 168 to set on power-up.  You don't need the coil in your logic.  Socket 1 defaults to TCP 20256 slave, so you don't need that, either.

I'd get rid of the powerup value in SI 104, too.  Set SI 104 to 0.  At 100, the PLC will wait 10 seconds before it unhooks from a "Connect" that has gone awry, and you're just muddying the water at this phase.

You mentioned you are connected via wireless.  Is the PLC on the same physical network as your wireless access point or is it at another site?  Are there managed switches in the loop somewhere?  There may be some latency in packet transfers - I've run into this with corporate networks and remote cellular systems.

To eliminate the network connection question, connect to the PLC with an Ethernet cable from your computer.  You need to do this test- I have not had problems with Ethernet-enabled PLCs going offline with a local hard pipe connection.  And I've done a lot of them.

You can set the TCP Retries timeout (SI 101) higher to something like 10 to see if it helps your wireless problem.  The units on that register is also 100 ms. 

Also, there's no rule that you have to use only SB2 to init your Ethernet card.  I always add a second self-resetting bit that allows me to edit the Init block or any other Ethernet stuff going on.  If you set the bit from a button, PLC logic, or from Visilogic you will loose connection but will be immediately able to re-establish it with the new parameters you've set.  Beats cycling power on the PLC every time.

Joe T.

 

[Rick_PN]

19 hours ago, Flex727 said:

Are you going to answer this?

I edited the first post with additional information. My posts need to be approved by a moderator and that takes time (8 hours+).

@Joe Tauser

I am aware of SB168  and SI104, both would not be there if the Ethernet would work. Same goes for Socket 1.

 

9 hours ago, Joe Tauser said:

You mentioned you are connected via wireless.  Is the PLC on the same physical network as your wireless access point or is it at another site? 

Yes it is. It is the same router - PLC on LAN cable, PC-LAPTOP on WLAN. - this is "setup1".

I do use other "setup2" which is - PLC on LAN, PC-Desktop on LAN (switch 10m away). Switch and router are connected via cable. And this connection experiences the same problems.

 

9 hours ago, Joe Tauser said:

PLC with an Ethernet cable from your computer

You mean like a crossover cable, direct connection PC-PLC?

Thanks for the initialize tip with MB0. But the strange thing is that it appears initializing is not the problem as this is successfully done. Why would it start working only by re-pluging the cable? What happens when the cable is re-plugged?

I attached some screenshots of parameter watches (via Serial connection) when Ethernet works or does not.

 

[Gabriel Franco]

I had similar problem once.  After a week strugling with it, I decided to install a new Ethernet card and problem was gone.  It may be a hardware failure .

 

[Joe Tauser]

9 hours ago, Rick_PN said:

You mean like a crossover cable, direct connection PC-PLC?

You don't need a crossover cable.  You can plug a regular cable from your computer to the PLC.  Or have the PLC and the computer plugged into the same switch.  My point is to remove all other components of the network.

To Gabriel's point - do you have another PLC or Ethernet card you can try?  These units are built by men - they are not without occasional fault.

Joe T.

[Rick_PN]

40 minutes ago, Gabriel Franco said:

new Ethernet card and problem was gone.  It may be a hardware failure .

That really is unfortunate.

 

14 minutes ago, Joe Tauser said:

My point is to remove all other components of the network

Will do. I had many combinations of connections before and it was getting the same behavior. But true, wasn't my priority to solve the issue back then.

 

I don't have another PLC or Ethernet card. It would be nice to get some information from hardware support if this is known issue and if some DIY fix exists (capacitor, resistor, diode or sth). After all it's a 70€ module (V100-17-ET2). From the look of PCB it shouldn't be complex ofc if only there is no defect in chips/ICs.

[Flex727]

19 minutes ago, Joe Tauser said:

You don't need a crossover cable.  You can plug a regular cable from your computer to the PLC.

Hmm, my experience is that a direct connection requires a crossover cable, but maybe it's a function of the ethernet card on the PC, older hardware, etc.

Regardless, follow Joe's advice and remove everything unnecessary, both hardware and software. In software, zero out the System Integers you are playing with and delete the Socket Initialization. You only need the Card Initialization & PLC Name - and double check that you are on the same subnet. Run IPCONFIG/ALL from the CMD window on your PC to make sure. You might try to create a new .vlp file with only the minimum necessities for ethernet comms. If that works, start adding the complexities until it fails. Then you will have your answer.

[Rick_PN]

I think datasheet https://unitronicsplc.com/wp-content/uploads/2015/12/V100-17-ET2_S_TECH-SPEC_10-13.pdf states that for PLC-PLC one needs crossover, but shouldn't that apply for PLC-PC too?

Will try to clean the code and run just this segment and then add complexity. Subnet is OK. 

Is there anyone on this forum with more insight into hardware of ethernet module?

[Ausman]

Many things have been covered here.   You need to go to the basics and start again with just the network ladderwork, which you do seem to be pursuing.

That said, has the 130 been connected to other things?  It is possible that the socket's pins have been damaged.  Check carefully that all pins are properly in line and same height.  Also try another cable.  And also reseat the adapter, ensuring it is done carefully and properly. 

If all that still fails, get another card to try.....even if you are an electronics whiz don't go trying to fix the unit.....Unitronics would much rather have it back for research if it is indeed faulty.

cheers, Aus

[Rick_PN]

Good points. But as mentioned I already switched cables and networks and the same thing happened. But worth a try.

It could be damaged, but nothing specific ever happened (like lightning strike or other power network related faults). I will check connections of the ETH module again.

Weird thing is that It can work 1h, 1 day,  non-stop, but then I download new project (via Ethernet) -> after downloading PLC RUN command is send -> sometimes Ethernet works (green LED is lit and orange LED is blinking). But other times (~20% chance) Ethernet does not begin to work (green and orange LEDs are lit - no blinking), even if it worked while downloading the project, just a few sec before. Ethernet never breaks while it is downloading the project or while I am connected with "Online Test" in VisiLogic.

[Ausman]

OK to all of that.  More thoughts, not in order of importance...just as the brain spat them out.

Did you actually check the socket pins?  There are many ports on these things and it is easy to put a wrong plug into the sockets if care isn't taken.  I have seen this result in bent socket pins that then don't align correctly to the plug.

When it breaks, I think you should go into info mode and see what the plc is saying about the port.  I'd also run a sniffer on the network and see what comes back.  Also try another address in your program and change the router etc appropriately.  Perhaps there is a collision happening that you aren't aware of as it isn't on all the time, and these tests might show it up.

Have you done a full reset and init?  Download an empty program and burn it.  Then go to Connection/Communicaton & OS/2nd tab Bottom Right button and work it.  Then Download and Burn your program and do a reset and init again, then see how it all goes.

Ask your supplier for a "loan" card to either fix the issue or eliminate the card as the culprit.  Either way it shouldn't cost you anything.

cheers, Aus

[Isakovic]

On 10/23/2018 at 12:14 PM, Ausman said:

Perhaps there is a collision happening that you aren't aware of as it isn't on all the time, and these tests might show it up.

I've seen this once. Connection was breaking because there was a card reader on the network with the same IP address.

What does "socket state 34" mean in your picture, I can't find it in help files?

If you already tried with keep alive registers, maybe try the next sequence:
When SB148 goes down (or some other condition that recognizes Ethernet problem) call socket close block, then delay, than initialize socket to UDP, then delay, then initialize it back to TCP. This resurrects blocked socket in my experience, maybe (probably) there's a more elegant solution.

Are there any other client applications besides you accessing via VisiLogic?

[Rick_PN]

Turns out V130 does not like some routers and I was unfortunate to have 3 of them.  I edited the first post for more detail.

I would like to say thanks to all who spared their time on my issue.

[Ausman]

Thanks for the detailed explain and reply.  Worth knowing.

cheers, Aus

[Flex727]

7 hours ago, Rick_PN said:

I edited the first post for more detail.

Thanks for this, but I'd like to point out (for others) that nobody gets notified - at least not in the normal way - when a post is edited. It's always better to do a new reply, quoting the relevant post as needed, rather than editing a previous post, even if you have to wait for moderation.

[Rick_PN]

I agree. That is why I posted new post with very short summary. But for future readers I think its more convenient to have the solution included in original (first) post. If they want they can scroll down to read other responses and discussion. The forum its less readable if the solution is buried between posts somewhere.

[Flex727]

3 minutes ago, Rick_PN said:

That is why I posted new post with very short summary. But for future readers I think its more convenient to have the solution included in original (first) post.

Yes, I definitely agree that's the best overall. Thanks.