It communicates fine when I first provide power. However, after just a few minutes it stops communicating. This is first noticed by attempting and failing to apply/remove power to specific (or all) devices. At this point, the device does not reply to pings either.
I have two of these units on the same board (to control power to more than 8 devices) and both are behaving the same which makes me skeptical that both units are broken.
I’m attaching a screenshot of the device info while it is still communicating.
Here the inactivity timeout is set to 3000 or 3 seconds. That means if I connect a tcp socket to it but do not send anything over the connection for 3 seconds the module will forcibly close the connection. This could explain what you are seeing.
However it’s also possible if you connect a TCP socket to the device and this inactivity timeout is set to 0(no timeout) then the socket is not gracefully closed the controller could think the client is still connected and thus would not allow another connection. So if inactivity is currently set to 0 try setting it to something like 10000 that way if your software crashes, computer shuts down, etc, then after 10 seconds the controller will drop the connection and allow a new one.
Thanks for the quick reply. The Inactivity time was set to 0 (no timeout), but the applications (client app or web page were not being closed). Does that tell you anything?
I’ll look at the manual to see if any of those other fields might be helpful. (Or purposely change the Inactivity time to something short and let it close the connection.)
Perhaps the latter would be easier to recover from than closing the app and removing/re-applying main power. (That’s currently the only way I’ve been able to recover.)
If inactivity time is set to 0 then the module is dependent on the socket being properly closed. If something happens like software crashes, computer shuts down, etc and the socket is not properly closed then the module does not know the connection closed and thus does not allow new socket connections. My guess is that is the problem. I would try setting that to 10000 and see if it resolves the problem. Note your software will need to send some type of keep alive message at least once every 10 seconds to maintain the socket. My suggestion is that software should connect to the device, send a command, get a response, then close the socket. Unless of course you are doing something like constantly monitoring the inputs.
Thanks. But the socket is never being improperly closed. The modules (both) just stop talking after a while.
One thing I noticed yesterday was that if I applied/removed power via the web interface every few seconds, module 1 never stopped communicating. However, as soon as I opened a second browser tab to communicate with module 2, module 1 lost communication.
We have a very simple use case for these modules. We’re only interacting with them manually via the client or web interface (so no automation). As a result, I’d rather not have to send a keep alive signal.
Given all that, perhaps your final suggestion would be the simplest solution. When you say “close the socket” in this context, are you suggesting we just close the client app or web page we’re using to communicate with the modules?
Most users send commands to the relay controllers via a TCP socket connection(default port is 2101). However it sounds like you are sending commands via HTTP? Can you confirm that? Maybe elaborate more on your application. When you say “We’re only interacting with them manually via the client or web interface (so no automation)” what specifically do you mean by client? Do you mean software connected to the module via a TCP socket connection over port 2101?
Right - software connected to the module via a TCP socket connection over port 2101.
The RJ-45 cables plugged into the two modules are connected to an ethernet hub. From there, I’ve got another RF-45 cable coming into my laptop, via a USB(-C) adapter.
Then I use either what I’m calling the “client” software app or a web browser to communicate with the modules. (See attached screenshots by those names.)
But when the modules stop communicating, they fail via both those methods.
Ok. So you’re just using the built in web interface or the Base Station software to communicate with the board. I thought you had developed your own software.
@Jacob do you have any idea why a ProXR Ethernet relay controller would stop functioning when being controlled by the Base Station software and then require a power cycle to begin functioning again? We have confirmed the inactivity timeout setting is set to 0 so it should be disabled.
Generally the only thing that will kill communications to these modules are:
A socket already being open to the module (you’re on a routerless network with only one computer and no internet/port forwarding so this seems unlikely)
If a socket is open to the module no other socket can connect outside of the port 80 web socket (http interface)
Network issues, you’re on a network with no real router so if this was the issue, it would be your computer restarting the Ethernet NIC to try and get a network or DHCP address
Hardware/load issue, this is a pretty broad category so I won’t go too in depth.
Can you get me the following info:
The Basic Settings (IP address, subnet, gateway) for both Ethernet modules and the settings on your computer for the Ethernet interface? On Windows you can use the command ipconfig from a command line or on mac the command ifconfig from the terminal to get your computer’s network info.
When this error happens there is an LED on the Ethernet module itself, is that LED lit up? This LED indicates and open socket to the module.
LED light when comm fails: yes, it still remains lit
Surface: does NOT appear conductive (and even if it is, the module is not screwed down). Looks like the black wires in the attached pic are the only connections to ground.
And maybe one more thing worth mentioning: previously, I used to see one of (not sure if both) the modules pop up in the “Discovered Network Devices.” (See attached pic, but ignore the fact that that IP ends in .150; that was on a different test station.)
However, these days, nothing pops up in the Discovered Network Device list. I just click on “Network” set the address and click OK and it starts talking (until it eventually loses comm).
I see no issues on the network setup for the modules nor the PC so that mostly rules out network. I would like to isolate it away from being an instance of a “smart” switch dropping the connections to either save power or prevent the UDP broadcasts over it.
That power supply should function flawlessly for this board so its unlikely to be the issue.
Because the web interface is still coming up, but comms through both the web interface and Base Station are failing I’m leaning more towards an power event issue though.
As for steps and info to isolate and resolve the issue:
What is being switched by the relays and is it an inductive load?
Is the 12VDC power supply used to power the boards shared by any other devices? Especially inductive devices
Try and directly connect an Ethernet module to your PC to bypass the switch and see if this issue reoccurs
If the load or another device sharing power with the relay controller are inductive I would try removing the loads and isolating the relay controller as an induction spike would explain this kind of activity on the board.
OK, great. Here are the responses to your latest questions/suggestions:
The devices being switched by the relays are circuit breakers for several 28 V navigation sensors (e.g. GPS receivers and other).
Nope - the 12 VDC PS is only being used for these two modules
Tried that previously (and again now) and that didn’t help. Also tried swapping around some of the ethernet cables, just in case and the problem remained the same.
Doing a test now where we’re pinging each module IP address to see if that works as a “keep alive” signal.
Unfortunately pings won’t work to act as a keepalive, but this issue can be mitigated with setting a keepalive value on the Ethernet module. This keep-alive is transparent to the actual communications and is more of a silent heartbeat message sent by one side or the other of a socket to make sure the other device is still there as it will respond with an acknowledgement.
Can you check the results of ipconfig again and see if any other networks have an IP address within 192.168.1.x on that computer? It could be something as simple as your computer not being sure which network to route the requests to. If you do have another network on that computer with the same subnet you can change the static IPs on the modules and your PC to be on a subnet outside of the other network’s range.
Because circuit breakers are inductive you should try removing the loads and see if this issue still occurs.
None of the other networks have an IP address within 192.168.1.x on this computer.
Was the suggestion to remove the loads of the circuit breakers just a test to see if one load in particular is causing a problem? (Because obviously, we need all the loads connected to support our effort.)
And BTW - I may not have mentioned this, but this set up used to work fine. But I took it over from someone else and have had this problem.
That said, as a coworker of mine pointed out, we are using a different laptop than we used previously, and this one was just one IT had lying around. He suspects the USB bus on the laptop may have an issue.
Removing loads for a test is primarily to rule out inductive spikes from causing power events on the relay board itself.
It would be unusual for a network adapter to be the issue. Maybe if its a USB to Ethernet/USB Hub adapter and the USB hub is drawing too much power and causing the USB port to reboot or if the USB port is faulty. Both would be uncommon, but you could try a different ethernet adapter or a PC with a physical Ethernet port. On that note you might also check the Ethernet cables from your PC to the switch or the physical RJ45 connections.
What you would expect if it was the PC side is something like the Ethernet port disappears and reappears or occasionally says something like identifying network.
Looks like I’ve got it narrowed down to either a PC hardware problem (USB port) or perhaps some kind of Windows/SW configuration issue:
I used my PC (instead of the lab PC) to communicate with the NCD modules and everything seems to be working fine.
I downloaded the latest version of the Base Station to the lab PC. I figured that wouldn’t matter (because the comm problem occurred regardless of whether I was using the Base Station or a browser to communicate withe the modules) and I was right.
I confirmed that the lab PC is using the latest .NET Framework
Both PCs are using Windows 11, Version 25H2 (with slightly different OS builds).
I know technically this is off of your plate now because the modules are working fine with my PC. But if you have any guesses on other software compatibility issues I could check before replacing the PC, that would be greatly appreciated.
If this helps at all, one difference I noticed between the two PCs is that when I open the Base Station app on my PC, the two modules show up in the “Discovered Network Devices.” But on the lab PC, although I can enter the appropriate IP Address in the “Network” field and start communicating with the modules, they never show up in the Discovered Network Devices list.
Either way, thanks to both of you for your fantastic support on this issue.
Its difficult to say for certain. Its either a Windows Firewall difference or an issue on the USB to ethernet adapter.
I believe UDP (which the discovered network devices section uses to discover the Ethernet modules) can be blocked by Window’s Default Public network firewall. Its possible that the USB adapter on the non-functioning pc was just set as a public network and thus blocking UDP.
That wouldn’t explain dropped TCP sockets, that sounds more like Windows just trying really hard to get internet on that specific ethernet port and just kept retrying to rebuild the network to get internet which would kill comms. Or the PC putting the USB port to sleep to save power.
Unfortunately its getting really into the weeds on Windows specific functionality, but that’s where I would start to look.
Shoot - I thought the Windows Defender suggestion was going to turn out to be it, but no luck there.
OK - it’s up to my IT guys from here.
Thanks again,
Roger
