4.4 Logs and Event History

This page shows what the BMS records, how to read the history with LiMon™ and how to save it for support. It also explains how far you can trust the times in the list and how to read a history after a fault.

Applies to

Boards: BMS1820, BMS3610, BCU2002, BMS1601, BMS1810.

4.4.1 How It Works

The BMS writes one entry each time an event starts or ends: warnings, protections, critical faults and the status events of the error bit table. The history holds up to 100 entries, 50 on BMS1810. When it is full, each new entry pushes the oldest one out. No board writes a log to a microSD card at present.

Fig.4.4.1: Where the Records Live and What Deletes Them

1 · In the BMS Saved copy kept without power saved regularly, at a restart, at shutdown Event history up to 100 entries 50 on BMS1810 newest first Battery Cycle kept without power shown in Live View Flush Logs deletes the history and the saved copy at once, no question 2 · In LiMon™ on the PC Fetch Logs Event Status list on the screen only replaced by the next Fetch Logs Screenshot the only copy of the event history, because LiMon™ has no export live values Log BMS Data live values while Start Log runs; kept on the PC per BMS Export Log one .zip file for each BMS, to send to support Clear Log deletes the log on the PC, after a question A restart, a shutdown and Default Settings keep the event history. A sudden power cut can lose the entries of the last minutes. Export Log holds the live values only: it does not contain the event history.

Table.4.4.1: What Each Action Does to the Records

Action Event history in the BMS Battery Cycle Log BMS Data on the PC
Restart System, shutdown kept; the next start adds its own entries kept kept
Sudden power cut kept up to the last save; the entries of the last minutes can be lost kept up to the last save kept
Default Settings kept kept kept
Flush Logs deleted kept kept
Clear Log kept kept deleted

4.4.2 Reading the Event History

Connect LiMon™, open Events › Event Status and press Fetch Logs. The BMS sends all its entries, which takes a moment. The list does not update by itself: press Fetch Logs again to see new entries. An empty history shows one row, NO EVENT. With a VIEWER licence the Event Status tab is locked.

Table.4.4.2: Columns of the Event Status List

Column What it shows
# Position in the list. Row 1 is the newest entry, so read from the bottom up to follow the order of events.
Status Detected: the event started. Cleared: the event ended.
Description The event number and name. The number is the bit number in the error bit table, where some events have a slightly different name: (0) User Support Need is User Attention Required, (27) Sleep Function Error is Sleep Cannot Execute, which means that a shutdown was requested while faults held both paths OFF, (31) PreCharge Error is Pre-Charge Fault, (32) System Initialize is System Power On, (38) Balance Progress Over Temp. Warning is Balancing Over Temperature Warning, and (33) to (35) write Multi-Master as M.M.
Timestamp Date and time of the entry; see 4.4.3.
  • Cleared means the condition ended. It does not mean that someone cleared it. For a protection, it is the moment the path may switch ON again, as described in 4.1 Protection and Recovery.
  • A Detected row without a Cleared row does not prove that the event is active now. A restart writes no Cleared row: an event that was active at the restart simply has none, and if it is still present it comes back as a new Detected row. The Pack Status tab shows what is active now (4.2 Monitoring).
  • Every start adds two rows: (32) System Initialize as Detected and as Cleared. They mark each start of the BMS in the list.
  • Entries with the same time were recorded together. They are listed by number, so their order says nothing about the cause.
  • Flush Logs deletes the history in the BMS at once, without a question. The list on the screen stays until the next Fetch Logs. Events that are active at that moment are recorded again as new Detected rows.

4.4.3 Time Stamps

The time comes from the real-time clock of the BMS, which a CR2032 battery on the board keeps running while the BMS has no power. Each time LiMon™ connects, it sets this clock to the local time of the PC. Nothing else sets it: the System Time in the CAN frame Device Info (0xB2) only reports it.

  • An entry keeps the time it got. A later connection, or a PC in another time zone, does not change the times of existing entries.
  • System Time is the local time of the PC. On a PC at UTC+3, it reads 3 hours ahead of UTC. A PC with a wrong clock sets a wrong clock in the BMS.
  • A clock that was never set, or one that stopped because its battery is empty, holds a date before 2020. The BMS then records how long ago each event happened, and LiMon™ shows the current PC time minus that age. These times are only approximate: the BMS does not count the time it was OFF, so an event looks later than it really was. LiMon™ puts no mark on such a row.
  • After LiMon™ has set the clock, new entries get the real time. Older entries stay approximate. On BMS1810 this starts with the next start of the BMS.

4.4.4 Saving the History for Support

LiMon™ has no export for the event history, so take screenshots: press Fetch Logs and scroll through the list until every row is captured. Do this before you restart the BMS or press Flush Logs, and also capture the Pack Status tab. Send them with the serial number, the firmware version and the LiMon™ version.

Log BMS Data on the Connection screen is a separate record that LiMon™ keeps on the PC, one for each BMS serial number. Start Log records the live values from that moment on: pack voltage, current and SoC, cell voltages and temperatures, and the events that are active. It records only while LiMon™ is connected and logging, and it stays on the PC until Clear Log. Export Log asks where to save and writes one .zip file for each BMS in the log. LiMon™ does not open these files; they are meant for support. Start a log before you try to reproduce a problem, because it shows what the values were when an event happened. It does not contain the entries of the event history.

4.4.5 Reading a History When Something Went Wrong

  • Start from the last (32) System Initialize before the problem. Everything above it happened in that run.
  • Warnings before protections. A warning shortly before a protection means the value moved slowly and the warning limit did its job. A protection with no warning before it means a fast change, or a warning limit too close to the protection limit.
  • Count the Detected rows of one protection since the last start. This is its trip count, which 4.1 Protection and Recovery compares with Error Recovery Attempts. A last Detected row with no Cleared row, together with (0) User Support Need, means that the limit is reached and the path stays OFF.
  • Look at the time between Detected and Cleared. It tells how long the path was OFF.
  • The same event right after every start is not a passing problem: it is present each time the BMS checks. Look for its cause in the settings or the wiring, for example the cell taps for (26) Cell Connection Error.

Example: the entries before an under-voltage trip (chosen entries and times)

The discharge path switched OFF during the afternoon. Fetch Logs shows these rows:

# Status Description Timestamp
1 Cleared (19) Low SOC 1st Warning Limit Exceeded 12.10.2026 15:52:00
2 Cleared (10) Cell Under Voltage Warning Limit Exceeded 12.10.2026 15:31:11
3 Cleared (9) Cell Under Voltage Protection Limit Exceeded 12.10.2026 15:27:40
4 Detected (9) Cell Under Voltage Protection Limit Exceeded 12.10.2026 14:49:02
5 Detected (10) Cell Under Voltage Warning Limit Exceeded 12.10.2026 14:48:31
6 Detected (19) Low SOC 1st Warning Limit Exceeded 12.10.2026 14:20:05
7 Cleared (32) System Initialize 12.10.2026 07:58:12
8 Detected (32) System Initialize 12.10.2026 07:58:12
  • Rows 7 and 8: the BMS started normally in the morning, with no event at the start.
  • Row 6: the SoC warning came about 30 minutes before the trip, so the SoC agreed with the cells.
  • Rows 5 and 4: the cell warning came 31 s before the protection, so the voltage fell under the load, with no sudden fault.
  • Row 2: a second cell was also low, so the warning stayed active through the trip. With one low cell, the warning clears at the moment of the trip.
  • Row 3: the protection cleared when the cells recovered during charging, 38 minutes later. There is one trip only, far from Error Recovery Attempts.
  • The battery was simply used too deep. Act on the SoC warning earlier, for example by reducing the load.
  • If row 6 were missing, the cells ran out while the SoC still looked fine. Check for a weak cell and check the capacity setting in 3.2 Capacity and SoC.

4.4.6 Checking the Result

  • The newest rows match what you saw on the system, and each (32) System Initialize matches a start you know of.
  • The times match the clock on the wall. If they do not, connect LiMon™ once so that it sets the clock, and treat older rows as approximate.
  • An event with no Cleared row is either shown as active on the Pack Status tab, or it was active at a restart.
  • The screenshots show every row, down to the oldest.

4.4.7 Common Mistakes

  • Pressing Flush Logs before reading. It asks nothing and cannot be undone. Take the screenshots first.
  • Expecting Default Settings or a restart to clear the history. Both keep it. Only Flush Logs clears it.
  • Restarting before looking. The history survives, but a restart ends what is active now, including User Attention Required and the trip counts. Check the Pack Status tab first.
  • Cutting the power right after a test. The newest entries can be lost. Read the history first, or use Restart System or a shutdown, which save it.
  • Taking a history entry for an active event. The list is the past; the Pack Status tab is the present.
  • Reading the time of a BMS whose clock was never set as exact. Connect LiMon™ before the test, so that new entries get the real time.
  • Reading the history too late. A warning that goes on and off near its limit fills the list quickly and pushes older entries out. Read the history soon after the event.
  • Sending only the Export Log file. It holds live values, not the event history. Send the screenshots as well.

The LiMon™ reference describes the screen: 6.2 Event Status.