I have two problems with my 2007(8?) ProXR (NER16xProXR rev.A), which I’m accessing via raw serial port to an python app that I wrote:
from the begining on (2008), the board used to from time to time reply with just 15 bytes to a command 0xfea7 (to get sensor data) instead of 16 bytes (e.g. I get 0x024302f50235000234036801c400b9 instead of 0x024102fe023500010233036901c300b8; the former is missing a 0x01 in the middle). Then it would go silent to any further commands, so I dropped the socket and connected again. Used to work until two months ago; now the unit sometimes refuses a new connection (socket says Errno 111: Connection refused), when I drop the socket. This persists even when I disconnect the ethernet cable from ProXR for 30s and reconnect. I can connect via web interface and check if there is a connection to serial (sometimes there is, sometimes not). The only remedy is rebooting the digiconnect ME. Any idea how to fix the issue?
Today I managed to disable web access to digiconnect ME by mistake. How can I factory reset it?
After I regain (web) access to digiconnect ME, is it ok if I update firmware or did you put some custom suff on the ME? Now I have 82000867_G POST and 82000856_F6 firmware. Do you have anything newer?
This could be an issue with a NAGLE wait time. These modules have been discontinued for a number of years so I’m not sure they even have a setting for this, but in essence the Ethernet module is sending a response before the full packet is built. A NAGLE wait time would reduce this happening if its an option on the module. If they do it would most likely be under Channel 1 > Serial Settings or Channel 1 > Connection
There should be two pins next to the Ethernet module marked reset. Power down the board, connect these two jumpers using a jumper pin or wire, and power back up the board with the pins jumped.
We no longer maintain firmware files for these modules. The firmware we use is customized so updating to the latest from Lantronix will introduce lost functionality.
I will check the NAGLE once I get to web interface (but usually it seems that a byte in the middle is missing, not sure if that matches the hypothesis)
there are no two pins but a button ‘RESET NETWORK INTERFACE’; I think it shorts pin 14 of ME to gnd, not pin 20 (it surely resets i.e.reboots the ME)
so if I understand correctly, if I update to EOS fw and POST fw (which seem to be latest), the thing won’t work anymore?
It being a byte in the middle makes it less likely to the a nagle issue. Seems like an issue with the serial buffer between the relay controller and the Ethernet module with it becoming unresponsive or it could be an issue with the TCP to serial driver being used. Its hard to tell without testing without the TCP to serial driver.
Unfortunately it looks like this version of our Ethernet Relay controllers actually didn’t have a factory reset functionality built in. I don’t have any documents letting me know if the pins under the Ethernet module are exposed, but if they are you can bridge pin 20 to ground during boot as outlined in this document from Digi: reset an ME or WiME back to factory defaults while it's on the Digi Prototype board | Digi International
Certain portions definitely won’t work such as the UDP discovery broadcasts, but we have not tested other firmware versions with our relay controllers to know if the command sets would still function.
Its possible that the hardware has just begun to break down and isn’t running properly. You could check that the power supply for the board is still outputting the correct power levels.
It will be software compatible with the commands you are already using although it has an expanded command set and now has an API wrapper for the commands that is recommended, but not required. It also has a Python library: GitHub - ncd-io/Industrial-Relay-Control
We don’t have a TCP to Serial driver for it, but you could try a generic virtual serial port driver or swapping over to a raw TCP socket.
