EN2SE-R "Update Mode" field


Do you have any availability for a phone call and teamviewer so I can review this with you?

The logs labeled log4_.txt don’t look consistent with the configuration you have running on the device. Have you tried logging using the test config I sent you? I would like to see if we see any thing similar with the linking device not producing any data.

I still believe something else on the bus is causing issues. Can you gain access to a 3rd party logger? Have you tested this without any device on the bus then adding them one at a time in addition to disabling nodes with the node monitor?

What is happening with Transactions 1 setup in node1? It does not look like a modus command. Deleting might clear up some of the issues you were seeing with node1.

Can you please let me know a phone number and when you can be available for a teamviewer session to review this issue.



See Red Text Below




Hi Howard,

ah it took me a bit to see you red text, the system strips our most of the old part of emails.

tried calling earlier. We are located in New Hampshire, but the number should be coming from a Chicago area code (312) 893-5636 I will try again tomorrow or feel free to call in and ask for me if my colleague picks up.

If Teamviewer is not possible I can host a webex to at least view your screen Webex possible?


Hi Howard,

The following PDF shows you how to use the jumper to reset the module.

Factory Restore Communicator.pdf (112.2 KB)



Jumper Reset had no effect on my results.

I changed the Config to just Node 5 (our CO2 sensor). (Config attached).

Attached are 3 log files.

LogJustRead5NoErrors shows all the query/response messages (Including the 1000ms reads of registers 200,218,210).

LogJustRead5Error1 shows a miss data log for the Probe Response (And probably ALL of the 1000ms queries).

LogJustRead5Error2 shows a miss data log for the 1000ms queries? and picked up halfway for the probe reply to read reg 100.

logJustRead5error2.txt (29.2 KB)

logJustRead5error1.txt (29.4 KB)

logJustRead5NoErrors.txt (29.4 KB)

JustNode5Reads.cfg (16 KB)

JustNode5Reads.cfx (6.51 KB)


Hi Howard,

I’m might be stating the obvious here but looking at these logs look like the serial device isn’t responding correctly. LogJustRead5Error1 looks like a request timed out where the Node didn’t respond. The Linking device then re-transmitted the same query and got a response.
LogJustRead5Error2 seems to show the slave responding to the request then send additional data that looks like a repeat of the end of the data. Based on the timing i don’t think it could be reflections on the bus and since it is clearly a repeat it wouldn’t be noise.

Just looking at these logs i would say there is an issue with the nodes you are communicating to. This might be a different issue then the one we were seeing where the linking device was sending erroneous data but it could be a symptom. If it is perhaps an issue with the logging this might be hard to track down with just the built in logging.

Discussing I asked my colleague regarding the transmit log data and he said the Tx data would only be data the Linking device sent. Which reinforces that there could be something going on with the linking device itself. If a factory reset does not clear up the issue swapping out the linking device is the only option I can think could resolve the issue.




Still looking at getting a new module for testing……

On a Different Note:

The steps to get a configuration to align with the Linking device and the PLC are not very clear to me.

I’ve have many instances where I thought I had the config saved but the next time I went back and looked, it came up with the Last setup. and the Module in the I/O tree was faulted with Error “parameter error” shown on the Connection Tab.

I also notice within the Configuration SW – when the SW is “Connected” the CheckSum LED is red. Where is this check stored in the PLC?

  1. The Probes have a Configuration we are setting (in EEprom) using the writes. Since we don’t want to continuously write to EEPROM we are using the Single Shot.

However, Since I fixed the last write query, the Probes now are un configured after the Linking Device starts.

If I unplug one of the Sensors, the Linking Device will re-do the single shots and everything is good again.

If I Download a new setup (I wanted to change the Update rate from 10 to 20 ms), the Probes become unconfigured again.

Also the same occurs if I power down the Linking device and nodes (a power up simulation).

Upon power up the Nodes become unconfigured. Again without an external comms monitor I don’t know what is being sent to the probes on power up.

I also don’t see anyway to restart the Module programmatically (Starting and Stopping the SubNet within the Configuration SW doesn’t seem to reset the Comms to re-transmit the Writes.)

Is the anyway to reset the Module programmatically?



Hello Howard,

Synchronizing the configuration is a bit confusing. I look at it by breaking it up into 3 key parts to make sure it is saved correctly.

  1. Linked device itself
    a. This is the configuration stored on the Linking device itself and needs to be downloaded with the configuration manager.
  2. AOP configuration.
    a.When you exit the program you should see a box pop up asking you to confirm that you want to save the config. Clicking yes will store the config for the Configuration manager to your project.
  3. Module definition.
    a. After saving the config and closing the Configuration manager the AOP needs to update the definition. This takes 2 steps 1) clicking ok in the definition window then excepting the changes. 2) Next you need to apply the changes to the project for the module properties.

Regarding your single shots. I would recommend setting up those commands to use triggered transactions over single shot. Then trigger them with the PLC by updating the trigger byte. This way they will not be getting triggered via the one shot which can not be manually controlled.




Still waiting for an Advanced replacement unit to try. I think the paperwork just went through.

In the Interim we did have an HMS Communicator device here (AB7072) so I thought I would try that.

We most likely won’t use it since this device requires Separate S/W and a Serial Cable to configure it.

(We are trying to use as much Ethernet connections and built it S/W for Configuration of Instrumentation and devices.).

Just to Test, I configured the device to talk to only one Probe. Same Messaging as previous. (4 reads and 3 writes).

I observed the Same issue with a blinking red light on the Subnet LED. (every 30 seconds or so).

Logging (continuously) on the Communicator (via serial cable) and captured after Red Light observed shows the same “Missing” data.

Since I had the “Linking device still in the panel, I decided to use that as a passive subnet monitor.

I connected it to the SubNet and configured it with the .cfg file you suggested (1 Consume instruction).

So I Ran the “Linking Device” Logging (continuously) and stopped it when I saw the Red LED flash on the “Communicator”.

Attached is a spreadsheet which contains 5 Logfiles.

I Highlighted the Query and Response messages (I only managed to capture the Reads)

RED = register 100,

GREEN=register 200,

BLUE=register 218,

YELLOW=register 210 (this is the order in which they execute).

As you scroll down you should see the repeating R-G-B-Y-R-G-B-Y…. colors. Then there is a misstep.

This is perplexing.

I’m not sure how the Linking device captures what appears to be missing data when the Probes must see it as they are responding.

(the log file picks up mid reply from a probe).

What am I missing here?

Do you do House Calls?

(Marlborough MA)

Any Thought?

CommunicatorErrors.xlsx (65.4 KB)


Hi Howard,

I was discussing this with a colleague and a scope capture of the bus might be the best option to see what is going on. We are wondering, like we discussed on the phone, that the communicators are running into issues due to something on the bus. This might be stopping the logging and then it ends up picking up with a when it recovers it starts the logs a time of zero.




Found a Scope! Can’t see any real issues…. Scope is hard to diagnose since the failure occurs on a 20-30 second frequency.

The only new info is that I can see a slightly different level in the Amplitude of the HMS device compared to the Probe. (HMS slightly taller).

This allowed me to see that the Probe sometimes doesn’t reply to a Query.

(scope freezes the last trigger and I can see the Query but no reply … Trace = Flatline).

I Think the RED light on the Gateway blinks at this instance but I had the Scope on the floor so it was hard to correlate.).

Still doesn’t explain what I see in the Logs.

So does this mean the bus has enough deviation such that the Probe doesn’t understand the query? (and doesn’t reply at all?)

If the probe knew the msg was for it, I think it should reply with an error message if the rest of the transmission was garbled.

Or maybe if the checksum is wrong (due to garbled data) it does nothing.

I tried the Bias resistors but it didn’t improve the Red Blink Rate (still about 1 per 20-30 seconds avg).

I’m still thinking on this end….


Senior Project Engineer


Hi Howard,

I think we are heading in the right direction here. I’m not sure I am following what you are seeing on the scope. Is this scope able to decipher rs485 data? Are you seeing the scope flat line when or around the same the error happens? Do you see a voltage change at this time or the bus going to 0v? Just theorizing but maybe something is happening to the bus that is effecting the RS485 transceiver and they are resetting. This might explain the “missing data” on the bus.




The Red Subnet Status LED does flash red when I see a “flatline” in the Scope Trace.

But not for every flatline. (sometimes I see the Flatline on the scope but no Red Light).

Below are a series of Scope Captures….

I have the Scope Probe gnd connected to the Panel Chassis DinRail so there is a little noise.

Bias resistors are installed for all but the last capture.

First you can see the HMS query amplitude is slightly Taller (which helps show the reply from the probe):

Here the Scope Horizontal scale is 2 seconds, Captured the 1 second timeout:

Here I zoomed in on the End of a (different) transmission… Looking for any Voltage Shift… looks ok?:

(The Top window shows the un-zoomed waveform and a grey box indicating the Zoomed portion).

Shows a Query and Reply then a Query:

Here I zoomed in on the Start of a (different) transmission after the 1 second timeout…

Again Looking for any Voltage Shift, or anything weird…

Different Transmission, Timeout, Zoom in on last query:

Different Transmission, Timeout, Zoom in on last query:

Just a Zoom in on the end of a query (different transmission):

This I captured after I removed the Biasing Resistors….

All the previous waveforms were captured with the Biasing resistors installed.

I can’t tell if any of this helps.



I’m getting a USB to RS485 interface to allow me to capture the Buss traffic separately from the HMS devices.

Have you (or others) done this and what S/W do you recommend (I’ve seen a few SW items on-line).

Also, Is pin 5 (Signal Ground) on the HMS also tied to the PWR connector GND? (currently pin 5 on our system is un-connected.



Hi Howard,

The device I was thinking of on the phone was a Saleae Logic Analyzer. The older ones only supported 0-5v and newer ones support ±25V. This would allow you to both capture similar to a scope but also decode the signal. It might be over kill go go out and purchase one of these but if anyone in your office happens to have one it might help identify what is going on with the bus.

Other then that i will wait to hear back with logs you can capture with the USB to RS485.



Got the USB to RS485 adapter and after trying a couple s/w packages got it to work.

It seems to load the Bus differently such that the RED SubNet LED on the HMS device takes 2-3 minutes between blinks.

So I only have one capture that I looked at so far with the new interface.

There was no erroneous data shown on the bus.

I am going to try to capture both the HMS Log and compare it to the Monitor S/W log.

But First I am trying to set up the new Linking device we received yesterday.

It is configured for IP from DHCP (vs manually set).

I am unable to change the IP address.

I downloaded the IPCONFIG tool (I had an older version that worked on the “Communicator” but not on the Linking Device).

The New Ipconfig SW that I just downloaded also does not see the Linking device.

What Am I doing wrong here……!!!



Hi Howard,

What do you mean by this? Are you saying its just preventing the errors from happening as often?

Did a log from the communicator or linking device look any different from the log taken with the USB>rs485? Can you share one of each taken at the same time.
Either version of the IPconfig software should work with the device. The software works by sending out a broadcast to have HMS devices respond. Make sure the software is not getting blocked by the firewall. What are the LED’s on the module doing? Does it show a link on the ethernet ports?

They also support bootp, you might be able to use this as an additional option to set the IP.


Yes, The errors happen less frequently with the USB to RS485 adapter connected to the bus.

I Tried to capture a simultaneous log with the Linking device and the Monitor SW.

Was not able to corollate the data between the two.

Not sure this first attempt even captured the error in the Monitor SW.

With this configuration (All 5 probes and all reads and writes) I Couldn’t find a missed probe response which is what I’m looking for.

I did capture a Missed Probe response with the Gateway and one probe:

You can see it send a read to address 0x64 (100decimal) to probe 1again after 500ms timeout.

Which begs to question.

If the Probes on occasion do not reply, and that is the Entirety of our issue, then Why am I not seeing this in the HMS logs?

If you recall I am running the Log “Continuously until I see the SubNet LED flash RED. (then press stop).

I just went back to the last set of 5 logs that I sent you, combined in the Spreadsheet, and None of them show this.

(no 500ms timeout and retransmission of the query).

Instead we see the Truncated (or what I’ve been calling Missing data).

Is it possible the Logging routine simply writes data to the buffer and when the index to the buffer reaches the end it just starts writing at the beginning of the buffer.

So when I press stop, the index could be pointing midway into the buffer and what is presented to the user is the Raw data in the Buffer and not adjusted for FIFO.?

So… How close to a transmission error is the RED led flash?


IPConfig SW doesn’t work with my Window’s 10 GE machine (Must be some Firewall issue).

If I connect to a VM through a USB Ethernet adapter I can get it to work.