EN2SE-R "Update Mode" field


#1

We have some Remote configurable probes (Analog sensors - pH, DO, CO2) that can be configured by writing data in the Output words. Originally the Update mode was set as Cyclical. However this would be writing to EEProm and this is not needed (or desirable) to continually write to eeprom.

I notice there is a Single Shot selection for Update Mode. Would this be the preferred mode to use for writing Configuration Parameters to the Probes? How does the Single shot handle Device power up or broken probes (no comms), etc…

Thanks,
Howard


#2

Hi @howardfb,

The Single shot will run when communication to the node is established. So for example if comms are lost it is not resent.
Triggered or on data change would be a better option as when these event happen is more controlled.

On trigger give you the most control and will only send a message when you update a trigger byte. This allows you to write data into the transaction then trigger as needed. This does require an addition parameter to manage.

On data Change is similar to triggere but it sends the message when the data object in the transaction is updated.

Deryck


#5

Deryck,

We have 5 probes connected to the EN2SE linking device. There appears to be some issue with the comms not being stable.

The Subnet Status LED will blink 4-5 green then 1 red (90 % of the time).

I was able to capture the transmission with the Logging feature but it seemed to miss some of the data.

I put the text file into a spreadsheet (attached) so I could annotate the Comms as I see it.

The comms looks good (Just reading the probe data) up to row 289…. Then it continues mid stream at 290 (reading probe 4) even though the relative time shows 0-1 ms.???

This is probably where the red LED blinks.

And where it continues you can see where it is performing the Single Shot Writes to the Probes (4 and 5) (due to the Xmit interruption).

I tried a few times to capture a data stream that had a 1000ms timeout midstream but was unable to achieve this.

I’ve also attach the HMS Config files.

Any ideas on how we trouble shoot this?

Thanks,

Howard

AopConfiguration.cfx (41 KB)

ProbeCommsIssue.xlsx (118 KB)

AopConfiguration.cfg (16 KB)


#6

Hi Howard,

This is an odd issue I have not seen the HMS-en2se-r ever send random incorrect messages like you have marked on line 290. I also don’t see any transaction that lines up with the data sent either.

You also flag the Node 4 FC16 write request. I don’t see any issues here this matches the Write Units request you have in the config for each node.

I think you are heading down the right direction and line 290 is showing you the transaction that is erroring out. The response seems to line up with the read DIag2 query, but i don’t see the actual query being sent.

I would recommend tracking down what is happening on line 290 or what might be cause the message to be in correct. If you take multiple logs do these lines always show up [0x02 0xE5 0xA5] ? If it does perhaps the configuration on the linking device is corrupt and needs to be rewritten. If this seem to be the case I would recommend doing a factory restore (tools > options > module) then rewriting the configuration.

It might be useful to use another device to check the serial traffic. There could be another device sending messages that is interrupting the linking device.

Deryck


#7

Deryck,

Thanks for the reply.

The Transmit info shown on line 290 I believe is the tail end of the request for Diag info for probe 4. The Previous request was for Probe 2 Holding registers Primary Channel.

The Logger missed the request for probe 3 (which from all the logs I’ve seen they are always in order).

I would have also expected to see a relative time of 1000ms somewhere in here for a missed reply.

If I disconnect a Probe, I do indeed get the 1000.

I’ve also Broken the Comms somehow at times (I can’t say exactly yet the sequence) but sometimes when I take a Log it just records nonsense (see below).

(Requires Power down of the unit – unless there is a Software method to reset the module).

Howard


#8

Also the Write (16) messages are Single Shot so I don’t expect this message if the system is running without comms issues.

But because I see the RED LED on the Subnet Status, I assume the Linking device then retransmits all Single Shots after a transmission fault.

**Howard **


#9

Hi Howard,

Sorry I over looked that the writes were single shot’s. That is very odd that they are being sent out in the middle of logging. the start up should be the only time your configuration would send those transactions. Does it looks like the Linking device reboots?

Can you try the factory restore to ensure we have a good configuration.

One trick to help see the what transaction is causing the issue is to start logging continuously and then stop the logging when you see LED 5 flash red. This should put the error right at the end of the log.


#10

The Linking Device very often emits the RED LED on the Subnet Status light.

To me this is a disconnect and the reason the single shots are being transmitted.

How do I do a factory restore? (Is that overwritten with the Config that I most likely will have to reload?)

Below is the last capture I tried (took a few tries) to capture the “Anomily”.

The Logger is missing transmission….

The log on the left is a normal transmission sequence.

The log on the right shows all transmissions as 0-1 ms apart however it did not capture Probe 4 or the beginning of probe 5.


#11

Hi Howard,

A factory restore is done from tools > options > module. The log looks like either there is another device on the bus responding, or the slave is not acting correctly and “talking” over the linking device.

Another thing that might be worth checking is the cabling on the bus, how long is the rs485 bus and is there termination and biasing?

Deryck


#12

Deryck,

I reset the Linking device and reloaded the Config. No difference.

We have a terminating resistor on the Linking device and the probes are plugged into a Turk Distribution module (that I assume we have configured with the proper loading).

I don’t believe there is another device talking out of turn on the network (it is not a long network… < 50 ft).

If you look at the attached log file there is a steady sequence of read (address 100) for Probes 1 to 5 repeating throughout the log until record 449 (shown below).

This is where the master requests reads of reg 200, 218, and 210. Then it requests a Write (16) to 120 even though this is supposed to be a Single Shot.

We have the Read reg 100 set at 10 ms and all others at 1second so you would expect what you see below EXCEPT for the write.

I still maintain that the Linking device is not logging data correctly.

Knowing the sequence of transmit and receive, the following is typical of what I am seeing for missed logging:

After sending a request for Probe 4 read register 100… the log file picks up mid transmission for the request for Probe 4 Write(16) (and the Probe 4 responds).

What is also missing is the reply from Probe 4 register 100, And the request & reply for probe 4 register 200, 218 and 210 which I normally see prior to the Write(seen above).

And The Time stamp shows a Relative Time of 0-1 ms for the missed data area…

Of further note, since we have a Request set at 10 ms for all the Probe Read reg 100, Why do I see a nominal 20 ms relative time shown at the start of the requests?

logc1.txt (29.4 KB)


#13

Deryck,

Any thoughts?

logc1.txt (29.4 KB)


#14

I have never seen the Linking device send messages it does not have downloaded in its config. The only explanation I can come up with is that you have another device, like a second modbus master, sending messages at the same time as the Linking device.

Do you have anything you could use to monitor the serial traffic besides the Linking device? I would be interested in seeing if a log from a 3rd party monitor picks up anything different. We could also monitor the bus without the linking device connected to see if there is any traffic.

A quicker test would be to download a empty config to the linking device and then log serial traffic to see if it picks up any messages still being sent. I would expect to see no traffic on the bus if the Linking device has an empty config. If we see other traffic we know something else is sending messages. Here is a config with the device set in generic data mode with only a consume transaction. This would set it up so it does not send any messages. testing.cfg (16.0 KB)

Deryck


#15

Deryck,

No 3rd party monitor available.

This is a Lab environment where we basically are bench testing 5 M100 Probes from Mettler Toledo through the Linking device to a Compact Logix controller.

There are no other ModBus Masters.

As an additional issue, sometimes when I connect to the Linking device and click on “Log” data, the TXD data is a random stream of info.

This has happened at least 7-10 times. (maybe 10% of my “logging clicks”)

And I’ve seen the following a few times (looks like the Xmitter is pulling data from the wrong place in it’s memory?)

( does “GS-Event GS-Timer”) look like something in the Linking device Code?)

After quite a few minutes of random data transmitting the Linking device starts requesting the proper queries from the Nodes.

However now the Probes have been Hosed with who knows what and are non responsive to all these requests.

(continued 1000ms timeouts to all query’s)

The only way to get them to reply is to power off the M100 Probes.

Pleas remember the Initial problem is the Continued RED Subnet Status LED blink every 4-6 green blinks and the previously sent Logs showing “Missed” data (not extra data).

Thanks,


#16

Hi Howard,
“GS-Event GS-Timer” would not be coming from the Linking device unless you had a transaction setup to send that message. It looks like it was not necessarily a modbus master but just another device talking on the bus at the same time. I would expect tracking down what device is sending this message and stopping it will clear up your communication issues including the periodic red #5 status light. My guess is the Mettler scales can be configured for an ascii mode in addition to modbus, or another device talking ascii is connected to the bus.

Deryck


#17

Deryck,

Who is in control of the “Data Logging”.

Since the MAX buffer size is 512 (per the manual), my suspicion is that the Linking Device captures the data (as apposed to the AOP running on Windows platform).

Thus anything I see on the Xmit side of the log I would come from the Linking device and anything coming back from the Probes would show up on the Recvd side of the Log.

Is this not the case?

When I do the Factory Reset, is the Linking device getting it’s firmware updated from the Rockwell AOP?

Also, Let’s verify what the latest version of the Firmware is available (if different from the AOP).

Below is what I currently have installed.


#18

Hi Howard,

The Linking device is logging the data then sending it to the software. The firmware does come from the Configuration software, and the configuration in a sorts programs some of it.

Thinking this over again I cant make sense of the traffic you are seeing. What i was thinking at first was the Linking device transmit transceiver would have been picking up the messages. This might make sense in an rs232 setup but not for rs485. The linking device wouldn’t be sending it unless you have a transaction setup for it.

I don’t see any configuration attached, i would like to take a look and see what is configured. Did you try the configuration I sent on the 3rd? This only has a consume message so you should not see any traffic on the Tx side.

It might help to take a look with on Via teamviewer along with a phone call. Would we be able to set up a time possibly this afternoon or next week?

Deryck


#19

Deryck,

Any reply to this?

It’s been over a week since I started this diagnostic effort. Is there any way we can speed this up?

Thanks,


#20

Deryck,

Attached is a group of logs:

Log4a to Log4e is the random data that I still think the Linking device software has it’s buffer pointers confused and is transmitting from somewhere inside it’s firmware.

(If you have a copy of the firmware you could open it with NotePad and search for the “GS-Timer” string to see if it is contained there).

Log4f - It eventually gets back to transmitting the Queries to the probes (that are now hosed and don’t reply).

Log4fff – After resetting the Probes all is back to normal (minus the few LED 5 red flashes).

The Next Series of Logs (5a,b,c,c) I have done the following steps:

(The Config file attached is for this set of logs)

Removed all Xmit queries and 1 of the Read Diag.

(Left Read PV query @ 10ms and 2 Read Diag queries @ 1000ms)

Then Increased all Read queries to 20ms.

Then using the Node Monitor, Disabled Node 1.

Each step increased the stability of the Comms incrementally, Less and Less of the RED Subnet Status LED flash.

Will run up to 30-40 seconds now between flashes.

Captured a few logs (log continuously and stop manually as soon as LED flashed RED.).

Full Sequence with all probes enabled should be:

log5cslowNoNode1.txt (29.3 KB)

log5cslowr.txt (29.3 KB)

HFB_AopConfigRead1to5slw.cfg (16 KB)

HFB_AopConfigRead1to5slw.cfx (21.9 KB)

log5b.txt (29.3 KB)

log5a.txt (29.3 KB)

log4fff.txt (29.7 KB)

log4f.txt (36.7 KB)

log4e.txt (36.7 KB)

log4d.txt (36.7 KB)

log4c.txt (36.7 KB)

log4b.txt (36.7 KB)

log4a.txt (36.7 KB)


#21

#22