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.