Scope of this technical record
Routes Siemens MASTERDRIVES F002 precharging evidence through line phase, fuses, precharge resistors, contactor/bridging path, DC-link capacitors, rectifier input and measurement evidence before any board purchase.
Do not repeatedly energize a MASTERDRIVES unit with an unresolved precharge fault. DC-link components can retain hazardous energy and failed precharge parts can be damaged further by repeated starts.
F002 precharge diagnostic image
First decision before troubleshooting
The maintenance team is usually trying to determine why the DC bus does not build correctly at power-up: failed precharge resistors, missing input, fuses, contactor, rectifier, DC-link capacitors or the measurement path. The answer must follow the energy path rather than naming a part too early.
F002 is a good example of why a thin fault definition is unsafe. A technician can destroy a repaired unit if the precharge path remains open or if the capacitors and input contactor are not proven before the next energization.
Fault timing is the first diagnostic measurement
The same drive family can show the same code for different reasons depending on when the event appears. The first useful evidence is not the replacement part number; it is the first fault, the operating moment and the measured boundary at that moment.
A code list defines the label. A service record defines what must be proven before the next energization or hardware purchase.
Timing-to-action map
| Observed event | Most likely branch to prove | Evidence that closes the branch | Stop condition |
|---|---|---|---|
| Immediately at power-up | Line phase, fuses and precharge path | Input measured at drive terminals plus DC-bus rise attempt | Do not bypass precharge or fuse protection |
| Bus rises then collapses | Bridging contactor or weak DC-link energy storage | Bus trend, contactor state, capacitor condition after isolation | Stop repeated power cycles |
| After repair or storage | Capacitor ageing, loose connection or workmanship | Pre/post repair photos, capacitor ESR/capacitance notes | Do not assume new parts fixed the root cause |
| Only in cabinet system | Upstream switchgear or common-bus precharge arrangement | Cabinet topology and which unit establishes the bus | Do not treat every inverter as standalone |
Repair boundary before replacing hardware
Legacy industrial drives are often repaired after production pressure has already caused several resets or swapped parts. The record therefore sets a boundary: prove the external energy path, the motor or field path, the command path and the measurement path before a board is treated as defective.
A good repair intake can often reject the wrong purchase. For example, a DC-link fault with missing input phase evidence is not a capacitor case yet; an overcurrent with a jammed load is not an inverter-board case yet; a field-loss code with open field wiring is not a control-board case yet.
Boundary proof table
| Boundary | What to check | What confirms it | What not to do |
|---|---|---|---|
| Input line | Measure at the drive input, not only upstream panel | Missing phase or voltage drop appears at the drive | Condemn DC-link parts from upstream measurements only |
| Precharge hardware | Inspect resistor, relay/contactor and charge route after isolation | Open resistor or failed bridging path matches bus trend | Bridge the charge path as a test shortcut |
| DC capacitors | Check physical condition and service history | Weak storage or leakage follows age/thermal pattern | Replace capacitors without proving input/precharge |
| Measurement/control | Compare displayed value with measured bus evidence | Mismatch suggests sensing or control problem | Trust one display value without measurement context |
Evidence package that makes the record actionable
A useful service record tells the technician what to collect next: model identity, first fault, trip timing, measurements, photos and repair history.
When this evidence is present, a service team can decide whether the next step is field wiring, supply correction, parameter recovery, board-level bench work, power-module verification or modernization planning.
Repair request evidence
| Evidence | Why it matters | Useful example |
|---|---|---|
| DC-bus rise curve | Shows whether precharge begins, stalls or collapses | Bus never reaches expected level before F002 |
| Precharge part photos | Identifies burnt resistor, contactor or connector damage | Resistor body cracked; contactor overheated |
| Topology evidence | Common-bus systems change the first branch | Rectifier unit feeds several inverters |
| Repair history | Repeated F002 after parts replacement points to root-cause gap | Capacitors changed but contactor not checked |
How this record supports a repair decision
Many fault-code references stop at the code definition. A practical service record has to connect the event to the field decision: inspect supply, DC bus, regenerative energy, motor cable, field circuit, communication topology, feedback measurement or board-level protection first.
This record keeps the path narrow. It converts the event into safe evidence, then states when the case becomes a board-level or component-level repair question before a drive is sent out or expensive parts are ordered.
Field record checklist
- Exact unit and voltage class
- When F002 appears
- Input measurements at drive terminals
- DC-link rise trend
- Precharge resistor/contactor evidence
- Capacitor bank condition
- Cabinet topology photos
Technical basis and reference documents
This is an independent editorial technical reference. Original manufacturer documentation remains controlling for installation, repair and commissioning decisions.
Used for MASTERDRIVES family terminology, DC-link behaviour and fault-reference boundaries.
Used to align fault terminology; the guidance is written as a diagnostic evidence route, not a raw fault-code copy.
Diagnostic workflow
Turn this record into a qualified service request
A repair decision is much more reliable when the request includes the exact identity of the drive, the first fault evidence and the machine condition when the symptom appeared.
- Complete drive type code / MLFB or nameplate model
- Fault code, fault value and first event before reset
- When the event appears: power-up, enable, ramp, run, decel or stop
- Motor/cable connected or isolated during the symptom
- Visible board, option-card, module and connector identifiers
- Previous repair history, replacement parts and repeat-failure pattern