Wrong Timestamps from a BMXNOR0200H: the Diagnosis and the Fix

A pump station RTU that reports the wrong time is worse than one that reports nothing. Every alarm it raises gets filed in the wrong place in history, every sequence of events reads in the wrong order, and the first time an operator notices is usually the first time somebody needs the event log to explain a trip. We hit exactly this on a Modicon M340 station reporting to a supervisory system through the BMXNOR0200H RTU module: values arrived correctly, but the timestamps on events were wrong at the SCADA end.

This article documents the diagnosis and the two-part fix, confirmed with Schneider Electric technical support, who reproduced the behaviour in their own lab from our program backup. If you searched for the part number with the word timestamp, this is probably the answer you are looking for.

The setup

The BMXNOR0200H is the RTU communications module for the Modicon M340 platform. It speaks the telemetry protocols a municipal or utility SCADA expects, holds its own datapoint configuration, and carries event timestamps to the master. Its configuration lives in two places at once, and that fact turns out to be the heart of the problem:

• The module's own web server, where the RTU datapoints are configured and mapped.
• The EcoStruxure Control Expert application, which holds the PLC program and must carry a matching copy of the NOR configuration, brought in through the module's export and import mechanism.

Symptom

Point values reached the SCADA and the protocol test tool correctly. Timestamps on those events did not. Depending on how your master displays it, this shows up as events stamped with a nonsense date, events stamped at the wrong hour, or a sequence of events log whose order does not match what physically happened at the station.

Root cause one: the two configurations had drifted apart

The first thing support found in the program backup was a mismatch between the variables in the Control Expert program and the variables in the NOR export. The workflow this module expects is strict: configure the datapoints in the NOR web server, export that configuration, and import it into the Control Expert application. Do it again every time the datapoint list changes. If the program moves on and the export is not refreshed, the module and the program are describing two different point lists, and what reaches the master stops being trustworthy.

This is an easy state to fall into on a live project, because nothing fails loudly when the two drift apart. The station keeps reporting. The mismatch only surfaces as subtle wrongness, and on our station the subtle wrongness was time.

Root cause two: the "Value with time" setting

The second finding is the one worth remembering, because Schneider's own engineers reproduced it directly. In the NOR datapoint configuration, a variable can be configured as "Value with time" or "Value only". With "Value with time" selected, the timestamps received on the SCADA and on the protocol test tool were wrong. With "Value only" selected, the correct timestamps came through.

The counterintuitive part is that the setting that sounds like the one you want for timestamped events is the one that broke them. The advice from Schneider Electric support was unambiguous: select "Value only" in the NOR configuration, then export and import the configuration into Control Expert so the program matches.

The fix, as a procedure

1. Open the BMXNOR0200H web server configuration and set the affected datapoints to "Value only".
2. Configure the module's time and clock synchronisation, so the station has a correct time source to stamp against in the first place.
3. Export the NOR configuration from the web server.
4. Import that export into the Control Expert application, so the program and the module carry the same variable list again.
5. Rebuild, transfer, and verify on a protocol test tool before declaring victory: raise a known event at the station and confirm the value, the order and the timestamp all arrive correctly at the master.

What this teaches about RTU projects in general

Two habits come out of this that we now treat as standard on every M340 and RTU delivery:

Treat the export and import as part of every change, not part of commissioning. Any device that holds configuration in two places will drift unless the synchronisation step is in the change procedure itself. The NOR export is not a backup formality; it is the thing that keeps the program and the module telling the same story.

Test timestamps explicitly, not incidentally. A commissioning test that checks values will pass on a station with broken time. The sequence of events log is a deliverable of its own: trigger events in a known order at the station and read them back at the master, with times. It is ten minutes of work, and it is the difference between finding this in the workshop and finding it after a trip investigation stalls.

Timestamps are also not an academic concern on this class of plant. The whole point of an RTU is that nobody is standing next to the station when something happens, which makes the event log the only witness. A station that reports with wrong time is a witness with a broken watch.

If you are working through a similar issue on an M340, a NOR module or an RTU integration and want a second pair of eyes, our PLC and RTU team works on exactly this class of problem across Abu Dhabi and the UAE, and our guide to RTU and telemetry projects covers how these systems are scoped and commissioned.