October 21, 2026
Posted by: editor
Category: RECD & Emission Control Devices

Controllers fail. A lightning surge on a monsoon evening, a water leak in a basement DG room, a display that stops responding after years of heat, or a supplier upgrade that needs new hardware. When an RECD controller has to be replaced, the hardware part of the job is usually quick. The data part is where sites lose things they later wish they had kept.

A new controller starts life with factory settings, a run hour counter at zero, an empty event log and a clock that may be set to the wrong time zone. Unless someone plans the swap, the site ends up with a history that stops abruptly on one date and restarts on another with different numbers, different units and no explanation. That gap matters when an auditor asks for a year of records, when the supplier needs regeneration history to judge a warranty claim, or when the maintainer is trying to decide whether the filter is due for cleaning.

This guide is a procedure. It is set out in three phases (before, during and after the swap) with numbered steps you can follow in order, preceded by an inventory of the data that exists and followed by an illustrative worked example and a printable checklist.

A reassurance first: the RECD filter itself keeps trapping particulate while the controller is out. What you lose during the swap is monitoring, alarms and, in active designs, heater or regeneration control. That shapes how you schedule the work, which we cover in Phase 2.

Know What Data You Are Trying to Save

Before you can preserve data, list what exists. Controllers vary, so treat this as a starting inventory and confirm against your controller’s manual or with the supplier.

Data type	Typical content	Why it matters	Where it usually lives
Trend logs	Back-pressure, exhaust temperatures, sometimes load or heater current, at set intervals	Shows filter loading pattern over time; supports performance and warranty discussions	Controller memory, SD card, or BMS historian
Event and alarm log	Alarm raised, acknowledged and cleared, power-on, faults, regeneration start and end	Compliance evidence; fault history	Controller memory, sometimes mirrored in BMS
Configuration settings	Alarm limits, delays, regeneration thresholds, heater setpoints, display units	Without them the new unit behaves differently	Controller only, unless documented
Cumulative counters	Run hours, regeneration count, hours since last cleaning, number of starts	Drive maintenance intervals; show device history	Controller memory
Calibration and scaling	Sensor ranges (for example 4–20 mA mapped to 0–100 mbar), offsets, sensor serial numbers	Wrong scaling gives believable but wrong readings	Controller settings plus calibration certificates
Communication settings and register map	Modbus address, baud rate, parity, IP address, register list	BMS and remote monitoring depend on them	Controller, BMS configuration, integration documents
Firmware version	Version number and any options enabled	Determines which settings and registers exist	Controller information screen
User accounts and passwords	Levels, names, credentials	Access control must be re-established	Controller and site credential register

Two points are easy to miss. First, some data lives outside the controller, in the BMS historian or a cloud portal, and may already be safe. Check before assuming you must extract everything. Second, some data cannot be exported at all on certain controllers. In that case, photographs of each settings screen and a written record of counters become the preserved copy. Our guide to what an RECD event log should record helps you judge which records are worth the effort.

Phase 1: Before the Swap

Most of the work happens here. If the old controller is still alive, every hour spent in Phase 1 saves several in Phase 3.

Step 1. Confirm why the controller is being replaced

The reason affects what you can recover. A controller with a failed display may still talk over Modbus, so data can be read remotely. A controller with water damage may not power up at all, and you will rely on the BMS and paper records. A planned upgrade gives you the most time. Write the reason in the change record.

Step 2. Raise a change request and agree roles

Replacing a controller is a major change. It touches alarm behaviour, possibly regeneration control and the BMS link. Agree who does what: the RECD supplier’s engineer for the controller, the DG maintainer for engine-side checks, the BMS contractor for mapping, and a site engineer to coordinate and witness. Who should hold which rights afterwards is covered in our post on RECD controller access control.

Step 3. Record the firmware version and hardware details of both units

Note the old controller’s model, serial number, hardware revision and firmware version. Ask the supplier for the same details for the replacement before it arrives. If the firmware versions differ, ask specifically whether any setting names, ranges, defaults or register addresses changed between them. This single question prevents many post-swap surprises.

Step 4. Export trend and event logs

Use whatever export the controller offers: USB, SD card, a service tool on a laptop, or a web page download. Common formats are CSV, a proprietary log file that the supplier’s software reads, or a text dump. Where possible:

Export the full history, not only the last month.
Save the native file and, if the tool allows, a CSV copy as well.
Name files with site, set, controller serial and export date, for example SiteA_DG2_SN12345_logs_2026-10-14.csv.
Note the time zone and date format the controller used. Many log in local time without saying so; some use UTC.

If the controller cannot export, ask whether the BMS historian already holds the same values. If neither works, photograph the on-screen history pages.

Step 5. Capture every configuration setting

Export the configuration file if the controller supports it. Even if it does, also make a human-readable settings sheet listing each parameter, its value and its unit. Configuration files sometimes cannot be loaded into a unit with different firmware, so the written sheet is your fallback. Photograph each settings screen as a third copy.

Compare what you capture with the last approved settings sheet. If they differ, find out why before carrying anything over. You do not want to faithfully copy an unapproved change onto the new controller.

Step 6. Record cumulative counters

Write down run hours, regeneration count, hours since last cleaning, number of starts and any other counters, with the date and time you read them. Also note the DG set’s own engine hour meter at the same moment. The relationship between the two is your best check later, because the engine meter will continue unbroken through the swap.

Step 7. Record calibration and scaling

List every sensor connected to the controller: type, range, serial number, input channel and the scaling configured in the controller. Pull the calibration certificates from the site file. Our guide on installed RECD sensor calibration documentation explains what a usable record contains.

Step 8. Capture communication settings and the register map

Note the Modbus slave address, baud rate, parity, stop bits, or IP address, subnet and port. Get a copy of the register map the BMS uses today, including data type, word order and scaling for each point. The Modbus Organization specifications define the protocol, but each device’s register list is its own, so do not assume a new controller uses the same addresses. Our post on RECD Modbus data, units and register mapping covers the common traps.

Step 9. Take a baseline BMS snapshot

With the DG set running at a known load if practical, record what the BMS shows for every RECD point alongside the value on the controller display. This gives you a reference for the after-swap test.

Step 10. Plan the timing

Pick a window when the DG set is least likely to be needed. In Delhi NCR, avoid GRAP peaks if your set’s operating permission depends on the RECD being demonstrably in service, and avoid known outage seasons. If the controller powers a heater or manages active regeneration, ask the supplier how long the set can run safely without it, and whether running should be restricted until the new unit is live. Our article on RECD controller heater power supply requirements is relevant if wiring changes are involved.

Step 11. Store the exports safely

Copy everything to at least two locations: the site file server and the facility manager’s records, for example. Do this before anyone disconnects the old controller. NIST SP 800-92 is a useful reference on protecting and retaining logs.

Phase 2: During the Swap

Step 12. Isolate and tag

Follow the site’s electrical isolation procedure. Tag the old controller with a label stating “Removed from DG2 on [date], retain for data, do not scrap” so it is not discarded before you are sure nothing else needs to be read from it.

Step 13. Label wiring before disconnecting

Photograph the terminal blocks and label each wire against the drawing. Sensor channels swapped during reconnection are one of the most common causes of believable but wrong readings, for example inlet and outlet temperatures reversed.

Step 14. Set the clock first

On the new controller, set date, time and time zone before anything else, so that every event it logs is stamped correctly from the start. Use IST unless the site has deliberately standardised on UTC, and match whatever the BMS and DG controller use. Writing timestamps in a consistent format, such as ISO 8601, avoids day-month confusion when logs are merged.

Step 15. Load or enter settings

Load the configuration file if the supplier confirms it is compatible. Otherwise, enter settings by hand from the settings sheet, one by one, with a second person reading back each value. Check units carefully: a limit entered in kPa on a controller set to display mbar is off by a factor of ten.

Step 16. Enter scaling and verify each sensor

Enter the scaling for each channel, then check the live reading against a known value. With the engine stopped, back-pressure should read close to zero and temperatures should read near ambient. If a reading is wildly off, check channel assignment and scaling before suspecting the sensor.

Step 17. Carry over cumulative counters

This is where sites take different approaches, and the right one depends on what the controller allows.

If counters can be preset: enter the old values, plus any run time that occurred between your reading and the swap. Record that you did this.
If counters cannot be preset: leave them at zero, and record an offset in the change record. For example, “New controller run hours = displayed value + 3,412.5”. Put the same offset in any spreadsheet or BMS calculation that uses the counter.
Never invent values. If you are unsure what happened between reading and swap, record the uncertainty instead of guessing.

The maintenance counters matter most. If “hours since last cleaning” resets to zero, the next cleaning reminder will come far too late. Check the RECD maintenance guide and set the next service date by calendar as well as by counter until the new controller’s numbers are trusted.

Step 18. Restore communication settings and access accounts

Enter the Modbus or IP settings, then set new passwords and user levels. A new controller usually arrives with defaults, which must be changed before the unit is left on the network.

Phase 3: After the Swap

Step 19. Run the DG set and compare with baseline

Run the set at a load similar to your Phase 1 baseline, after enough warm-up for exhaust temperatures to stabilise. Compare the controller display with the earlier values. Readings at similar load should be in the same range, allowing for filter loading since the baseline. Our guide on comparing RECD pressure readings at different generator loads explains why load matching matters.

Step 20. Re-test the BMS mapping point by point

Do not accept “communication OK” as proof. Communication can be healthy while every value is wrong because of a word order or scaling change. For each mapped point, compare the BMS value with the controller display and tick it off. Then force or simulate each alarm, where it is safe to do so, and confirm it appears on the BMS with the right text and priority. If the BMS shows a communication alarm during this work, our post on what happens when RECD communication fails covers how to diagnose it.

Step 21. Check timestamp continuity

Look at the first events logged by the new controller and the last ones exported from the old one. They should line up in time with the DG controller’s own log and with the change record. Note the gap period explicitly. A gap you can explain (“controller out of service 11:05 to 14:40, set not run”) is far better than one an auditor discovers. Our guides on aligning RECD sensor timestamps with generator runtime logs and detecting missing data in RECD monitoring records go deeper.

Step 22. Merge the historical record

Combine old exports and new logs into one continuous record for the site file. Keep the original export files untouched and work on copies. Add a note at the join stating the swap date, both serial numbers, the counter offsets and the gap period.

Step 23. Update documents

Update the asset register, the settings sheet (with the new serial number and firmware), the BMS points list, the calibration record and the credential register. If the supplier issued a new type-approval or compliance document referencing the controller, file it with the RECD records.

Step 24. Decide what happens to the old controller

Keep it until the new unit has run without problems for an agreed period, often a month or so. If it goes back to the supplier for repair or warranty assessment, record that, and wipe or change its credentials if it will be reused elsewhere.

Worked Example: A Controller Swap at a Hospital (Illustrative)

This is an illustrative scenario with assumed numbers.

Situation: A 200-bed hospital in Noida has a 1010 kVA DG set with an RECD. During a storm in September, a surge damages the RECD controller’s display. The controller still communicates with the BMS, but no settings can be viewed locally. The supplier confirms a replacement controller with newer firmware will arrive in four days.

Phase 1 (days 1–4):

The site engineer raises a major change request with the supplier, the DG maintainer and the BMS contractor.
Through the supplier’s service tool on a laptop, the engineer exports 14 months of trend logs (about 41,000 rows at 10-minute intervals) and 1,860 event log entries as CSV, plus the native configuration file.
Counters read at 10:20 IST on day 3: run hours 2,847.6, regeneration count 312, hours since last cleaning 186.4, starts 1,094. The engine hour meter reads 9,215.3 at the same time.
The supplier confirms the new firmware moves two registers (exhaust outlet temperature and alarm status word) to new addresses and changes back-pressure from integer mbar to a value with one decimal place (scaled by 10).
A BMS baseline is captured at 60% load after 20 minutes of warm-up: back-pressure 48 mbar, inlet temperature 412 °C.

Phase 2 (day 5, 10:00 to 13:30 IST):

The swap is scheduled for a weekday morning with grid supply stable and a rental DG on standby for the critical loads, in line with the hospital’s own retrofit practice.
The clock is set to IST first. Settings are re-entered by hand, because the supplier advises the old configuration file is not compatible with the new firmware.
Between the counter reading and the swap, the set ran for a 1.2-hour test. The new controller allows counters to be preset, so run hours are set to 2,848.8 and hours since cleaning to 187.6. Regeneration count is set to 312, and starts to 1,095.

Phase 3 (day 5 afternoon to day 6):

At 60% load after warm-up, back-pressure reads 49 mbar and inlet temperature 409 °C, consistent with the baseline.
The BMS initially shows back-pressure as 490 mbar. The BMS contractor applies the new divide-by-10 scaling, and the value correctly shows 49.0. The two moved registers are remapped and each alarm is simulated and confirmed.
The change record notes: “RECD monitoring unavailable 10:05 to 13:20 IST on day 5. DG not run in this window. Filter in service throughout.”
A check of engine hours against RECD run hours shows the same difference before and after the swap (within 0.1 hour), confirming the counter carry-over.

What could have gone wrong: Without the firmware question in Step 3, the BMS would have shown back-pressure ten times too high. Operators might have stopped the set unnecessarily, or worse, the BMS alarm limits might have been “adjusted” to suit the wrong reading. Without the preset counters, the next cleaning reminder would have arrived about 187 run hours late.

Printable Controller Swap Checklist

Before

Reason for replacement recorded
Change request approved; roles agreed
Old and new firmware versions recorded; differences confirmed with supplier
Trend logs exported (native and CSV), files named and time zone noted
Event and alarm logs exported
Configuration file exported; written settings sheet made; screens photographed
Settings compared with last approved sheet
Counters recorded with date, time and engine hour meter reading
Sensor list, scaling and calibration certificates collected
Communication settings and register map recorded
BMS baseline captured at known load
Timing agreed; standby arrangements in place
Exports stored in two locations

During

Isolation done; old controller tagged “retain”
Wiring photographed and labelled
Clock and time zone set first
Settings loaded or entered and read back
Scaling entered; each sensor checked at rest
Counters preset or offsets recorded
Communication settings entered; default passwords changed

After

Running comparison with baseline at similar load
BMS points verified one by one; alarms simulated
Timestamp continuity checked; gap period recorded
Historical records merged with join note
Asset register, settings sheet, points list, calibration and credential records updated
Old controller retention or return recorded

Frequently Asked Questions

Can we just copy the configuration file to the new controller?

Sometimes. It usually works when hardware and firmware are identical. When firmware differs, the file may load partly, fail or load values into the wrong parameters. Ask the supplier, and always verify against the written settings sheet afterwards.

What if the old controller is completely dead?

Use whatever survives: BMS historian data, any cloud portal records, the last approved settings sheet, logbooks and maintenance records. Estimate counters from the engine hour meter and service records, and state clearly in the change record that the values are reconstructed.

Is it acceptable to reset the run hour counter to zero?

It is acceptable if you record a clear offset and apply it wherever the counter is used. Leaving it at zero with no note is not good practice, because maintenance intervals and device history become unreliable.

Do we need to retest RECD performance after a controller swap?

A controller swap alone does not change the filter, so an emissions retest is not usually expected. However, confirm alarms, sensors and any regeneration control work correctly. If other DG or RECD changes happened at the same time, see when to retest an RECD after DG set changes.

How long should we keep the old controller’s exported data?

Keep it as long as your site keeps other RECD and compliance records. Many sites align it with their audit cycle and the device’s warranty period, and keep it for the life of the RECD.

Plan the Swap Before You Need It

The best time to prepare for a controller replacement is while the current one is healthy: keep an up-to-date settings sheet, export logs regularly and record counters at each service. Aceget supplies CPCB type-approved Retrofit Emission Control Devices for DG sets from 25 kVA to 2500 kVA. To check documentation for your installation, see our certifications or contact our team.

How to Preserve RECD Data When Replacing a Controller