Ethernet locks up

[davidbgtx]

My Do-More intermittently "locks up the ethernet port", sometimes days apart. When it happens it stops communicating with my C-More, the 450 ECOM, and cannot connect laptop to troubleshoot. DO-More is still in run. Switching the RUN/TERM/STOP switch to Stop then back to run doesn't help. Cycling power to Do-More seems to be the only way to restart Ethernet communications. See attachment pics for my setup, I have increased timeouts, didn't help
. You can see (Wed June 3) the log does not show any fault (after I cycled power and could connect laptop), but ethernet was locked up. Not sure how to troubleshoot this when I can't connect with laptop.

[BobO]

USB or serial should still be functional.

When you power cycle the PLC, are you also power cycling the Ethernet switch the system uses?

What Do-more OS version do you have?

There are a number of diagnostic registers I'd like to see, but let's start here.

[davidbgtx]

USB or serial should still be functional.

When you power cycle the PLC, are you also power cycling the Ethernet switch the system uses?

What Do-more OS version do you have?

There are a number of diagnostic registers I'd like to see, but let's start here.

I am cycling power to ethernet switch also, hadn't thought about that, I had ruled it out because I was unable to connect to the PLC directly with a crossover cable. Next time I will only cycle power to the PLC, then the switch, or vice versa.

Designer 1.3.1

[plcnut]

Do you always run with no Gateway?

[davidbgtx]

Do you always run with no Gateway?

yes, no routers, only unmanaged switches

[BobO]

If it didn't talk with a crossover, it probably isn't the switch (assuming the crossover is good). Switches do cause issue more than most are aware, so we always recommend folks cycle power on them independently of the PLC.

Please monitor the following, and let me know if they contain anything but 0.

$QueuesFlushed (ST145)
$CommStackOverrn (ST146)
$DebugTrapAddr (DST411)

If you have created any custom protocol devices like TCPClient, TCPServer, or UDPConnection, and are not servicing them in code, delete them. They can accumulate packets in their queues, and in some cases can deplete the system of shared network resources.

[davidbgtx]

If it didn't talk with a crossover, it probably isn't the switch (assuming the crossover is good). Switches do cause issue more than most are aware, so we always recommend folks cycle power on them independently of the PLC.

Please monitor the following, and let me know if they contain anything but 0.

$QueuesFlushed (ST145)
$CommStackOverrn (ST146)
$DebugTrapAddr (DST411)

If you have created any custom protocol devices like TCPClient, TCPServer, or UDPConnection, and are not servicing them in code, delete them. They can accumulate packets in their queues, and in some cases can deplete the system of shared network resources.

Below are current monitored values, do they get cleared after power cycle, do I need to get them when ethernet is locked up before power cycling?
ST145 off
ST146 Off
DST411 0

Ihave attached pics, no custom protocols

[BobO]

DST411 is retentive. The others are not.

When the Ethernet was not responding, did you notice whether the Eth LED was indicating a link and activity?

Next thing I am going to want is a Wireshark trace when things aren't happy. Run it from the programming PC, while attempting to connect with DmD.

This one's a bit odd, but comms aren't magic. It's like a small engine...air + gas + fire = run. If packets are getting there, we are processing them, sending responses, and packets are getting back to DmD, comm should work. If comm isn't working, that pathway is breaking down somewhere, and we will find it. May end up needing to do some diagnostic firmware that lets us get more info while failed. It will be important to have USB or serial programming working to get access...ECOM100 could work too, if you have one lying around.

Please send an email to support@hosteng.com with your contact info. That will be better than trying to use the forum.