Most tricky motor-controller problems don’t happen in the lab. They show up once in a while at a customer site – under just the wrong combination of load, temperature, supply and user behaviour. Without field data logging, you are guessing. With it, you can see exactly what the controller saw in the seconds before an issue.
Why field data logging matters for motor controllers
- Reproducing rare faults in the lab becomes much easier.
- FOC tuning and protection decisions are based on real usage, not assumptions.
- Product teams get hard evidence for discussions about requirements and margins.
Good logging is a multiplier for your FOC work (real-time optimisation, control loop integration, start-up & low-speed tuning) and for protection & fault testing.
Step 1 – Start with questions, not with signals
The fastest way to create an unusable logging system is to “log everything, just in case”. Storage fills up, bandwidth is gone, and nobody looks at the data. Instead, start with a short list of questions:
- Which failures are expensive or hard to reproduce? (random trips, noisy operation, jerky start-up, etc.)
- Which behaviours do you want to understand better? (real load profiles, duty cycles, temperature usage.)
- Who will actually look at the data – and what decisions do they need it for?
From these questions you can derive the minimum set of signals and time resolution you need.
Step 2 – Choose the right categories of signals
For motor controllers, useful signals typically fall into four groups:
- Electrical: phase currents (or dq currents), DC-link voltage, motor voltage commands.
- Control & state: speed/position, torque reference, control mode, state machine, error codes.
- Environment: temperatures (power stage, motor, ambient), supply conditions, battery state.
- Meta / context: firmware version, configuration ID, uptime, usage counters.
Not all of these need full time-series logging. Some are best captured as “snapshots” or long-term counters rather than high-rate signals.
Quick map: symptom → minimal signals to log
| Symptom | Key signals | Notes |
|---|---|---|
| Unexpected overcurrent trip | Phase currents / Id, Iq; torque ref; DC-link; speed | Log a short window before and after the trip event. |
| Noisy or rough start-up | Speed / position; Id, Iq; mode state; start-up flags | Helps tune start-up ramps and detection thresholds. |
| Random resets / watchdog | Reset reason; uptime; mode; last error code | Event log is more important than high-rate samples. |
| Thermal derating too aggressive | Temperatures; output power/torque; speed | Shows how often and under which conditions derating occurs. |
| Customer says “no power” | Supply voltage; enable signals; error and lockout flags | View whether it is really a drive issue or external. |
You can extend this table for your own products – it’s a good alignment tool between development, test and field/service teams.
Step 3 – Design event-triggered logs, not permanent data fire hoses
Continuous full-rate logging to flash or the cloud is rarely practical. A more robust pattern is event-triggered logging with pre- and post-trigger buffers:
- Maintain a ring buffer in RAM for a handful of high-rate signals (e.g. Id, Iq, speed, DC-link).
- When an event happens (fault, watchdog, mode change), freeze and persist the buffer.
- Add a short post-trigger window if possible (e.g. a few dozen milliseconds).
In parallel, keep a lower-rate “health log”:
- Aggregated statistics (max/min/average) for temperatures, torque, speed.
- Counts of specific errors, restarts, operating hours per mode.
- Occasional snapshots of key configuration values.
This combination gives you detailed waveforms around critical events plus a long-term view of how the product is actually used in the field.
Step 4 – Make log records self-describing
Field data is often analysed months later by someone who was not involved in the original design. Make their life easier by making each log record self-describing:
- Timestamp (relative uptime or absolute time) in a clear format.
- Signal identifiers that match your internal documentation.
- Units and scaling (e.g. “0.1 A per LSB”, “0.01 °C per LSB”).
- Firmware version, hardware/variant ID and configuration ID.
Even for very constrained MCUs you can encode this compactly. The key is to keep the mapping between IDs, units and meanings under version control together with your firmware and tests.
Step 5 – Choose storage and extraction paths that fit your product
How you store and extract logs depends heavily on your device class:
- Service-tool based products: logs stored in flash/FRAM and read out via UART, USB or CAN during service.
- Connected products: logs periodically uploaded via gateway or mobile app, with local buffering.
- Resource-constrained devices: only last N critical events stored, exported on demand.
In all cases:
- Protect logs from accidental overwrite before they are read (e.g. use a simple “sealed” flag).
- Consider privacy and regulatory aspects if logs include user-related data.
- Plan a simple workflow for support staff: “how do I get the logs off the device?”.
Step 6 – Integrate logging into your overall drive and test strategy
Field logging is most powerful when it is aligned with the rest of your development and test approach:
- Use the same signals and naming in field logs, lab logs and real-time optimisation / tuning sessions.
- Feed insights from field logs back into your protection and fault-handling design: protection & testing.
- Align logging with the maturity of your drive system – see your internal equivalent of a “prototype to series” maturity model for drive systems.
- Include logging checks in validation: can you trigger, store and read logs reliably?
For STM32-based motor controllers, this is also where remote testing & motor control consulting can help – for example by defining minimal signal sets and log formats that work across a whole product family.
Step 7 – Keep data volumes under control
A common fear is that logging will blow up storage and bandwidth budgets. You can avoid this by:
- Being strict about which signals get high-rate logging (only those needed for dynamic analysis).
- Compressing data where appropriate (delta encoding, shorter sample width).
- Using aggregation for long-term trends (histograms, min/max/average instead of raw streams).
- Defining retention policies: how many events to keep, when to overwrite, when to export.
Often the biggest win is cultural: agreeing that logs are for answering specific questions, not for “recording everything forever”.
FAQ: Field data logging for motor controllers
Do we really need high-rate current and speed logs in the field?
Not always. High-rate logs are most useful around specific events (trips, start-up, mode changes). For many products, a triggered ring buffer plus lower-rate health logging is enough. Full continuous logging is rarely necessary outside development or lab setups.
How is field logging different from lab logging?
In the lab you control the test and can re-run it. In the field, you get only what the product captured in the moment. That makes robustness, self-description and minimal but meaningful signal sets much more important.
Where should we implement logging: in the motor control MCU or elsewhere?
For STM32-based drives, core dynamic signals (currents, speed, torque reference) usually live in the motor-control MCU. Aggregated statistics and event logs may also be mirrored to higher-level controllers or connectivity modules. The architecture depends on your overall system and update strategy.
Can logging itself cause timing or reliability issues?
Yes, if done carelessly. Logging must not interfere with your real-time control loops. That’s why it is often designed alongside real-time optimisation and tested as part of your FOC and protection validation. DMA, double-buffering and careful task prioritisation are your friends here.
Next steps if you want to introduce or clean up field logging
If your current products either lack field logs or produce too much unusable data, it usually helps to start small:
- Pick two or three high-impact issues and define the minimal signals needed to analyse them.
- Implement a basic event-triggered log around those cases on one product line.
- Test the end-to-end workflow: from fault in the field to log on an engineer’s screen.
Once that works, you can extend the approach across more variants and integrate it with your wider drive systems and firmware development. If you want support with defining signal sets, triggers and formats, a short engagement via engineering & firmware consulting or STM32 motor control consulting is often enough to get a robust foundation in place.
0 Kommentare