HMS-EN2SE-R Node Missing Error


I recently added a new device to a Modbus RTU (RS485) network, using a HMS-EN2SE-R (in master mode) to communicate via Ethernet/IP to a ControlLogix PLC. I have two devices on the Modbus network. I can successfully read the data from these devices, and their values matchup with the physical readouts on the devices. However, on the HMS-EN2SE-R, LED 5 flashes green several times, then goes solid red for a few seconds, before returning to flashing green and repeating. Within the configuration manager, the subnetwork status has a constantly incrementing value for Retransmission Error, and Node Missing indicates that node 01 is missing. As stated, all data is coming in correctly from this device, so it does not seem like the node could be missing. I have tried varying baud rate, stop bits, message delimiter, and parity, all to no avail. How can I get rid of these errors?

Node 01 is the original device, and node 02 is the new addition. Within the configuration manager, all three green indicators along the bottom of the window are green.

Current settings:

Message delimiter = 50

Thank you for any help you can offer,


Hello @a_keith,

If led 5 is periodically flashing red you most likely have 1 transaction not working or randomly timing out. You should be able to use the logging in the ACM tool to take a log of the subnetwork and look for either an error response message or query without a response. is a good resource for understanding an error response.


Hi @deryck_hms,

Using your advice, I was able to identify two transactions causing issues, one of which I was able to fix. However, the other problematic transaction, a ‘Write Single Coil’, gives the result in the image below. I tried lowering the delimiter, and raising the update time, neither of which fixed the issue.

Thanks for your help so far, I hope we can get this issue figured out as well.


It looks like messages are talking over each other. Can you send your configuration and a export of a complete log for me to look at? This might allow me to make a better judgement and suggestions for a fix.


Looking at the configuration and logs you PM’d me I am not sure what is causing the LED 5 to flash. It does look like node 3 takes a while to respond. I would recommend setting the default message delimiter again. You could try a larger time but I am doubtful this is the root of the issue.

Regarding the log that looks like an error, the log feature does circularize the log file. You are seeing the weird messages at the location where the new log has started over writing old messages. If you use the log until full option I suspect you will not see this in the log. To help catch the messages in error I would recommend start logging, with the log until full option, and stop logging when you see the LED flash red. This should put the error message right at the bottom of the log making it easier to find.


I have messaged the files, but I will post them here as well.

current-config.cfg (16.0 KB)
current-config.cfx (34.0 KB)
trans-err.txt (31.1 KB)

Thanks your help. I will go grab a log using your advice. I will follow up with you here once I troubleshoot further.


1 Like

I followed your advice and logged the data using the ‘log until full’ option and I stopped logging when the red light came on. At line 412 in the attached text file, it appears as if the requests are running into each other.

error-log.txt (31.1 KB)


Was this taken using the same configuration you shared previously?


Are you sure the Node supports function code 5? It looks like the device is simply not responding at all to the query. I would expect the device to send some response but perhaps it doen’t follow the modbus spec in this instance.


The documentation for the device says that that is a 0x005 node. Since it is basically an on/off bit, that seems correct to me. It is strange that there is no response at all. I’ll try playing around with the command to that node today and follow up with you tomorrow morning. Thanks again for your help!


So it turns out that the transaction that was timing out was a dummy transaction set up by the person who initially configured the gateway. He said that the gateway required some output to allow him to download the configuration, and his solution was to set up a dummy transaction.

I configured that transaction to only update on trigger byte change. Since the trigger byte is not being used, this transaction will not occur. This has fixed the issue with both the flashing LED and the long response time.

Thanks for your time @deryck_hms, you have been extremely helpful.


Hi @a_keith,

Thanks for follow up glad to hear you have it sorted out. Have a great week.


1 Like