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.
