Draft article / Drives / VFD / en
Drive repair or exchange: the intake decision
A repair or exchange partner can only judge what your request shows, so send identity, symptoms, and configuration in full, never a fixed verdict.
The question this guide answers
What makes a drive suitable for repair or exchange review?
1. Which identity fields open the request?
Identity is the first thing a partner needs, and it means more than the main reference. Send the complete catalog number with every suffix, the hardware revision or date code, and the serial number if the plate shows one. Two drives sharing a reference but differing in revision can need different spares inside the same repair, and the serial number lets a partner check for any service bulletin covering the unit.

Diagram unavailable.
A nameplate photo attached to the request settles transcription doubts for free. The photo carries the small print that typed notes flatten: the exact suffix order, the option codes, the plate layout. If the plate has already been replaced by a repair shop, say so, and photograph whatever identification the new plate carries, because a replaced plate is itself a finding the partner will want.
Identity is also what makes the request searchable. Partners work across hundreds of units, and the request that can be matched to a family, a revision, and a serial number gets looked at sooner than one that says the brand and a rough power figure. The nameplate article in this series covers how to read and capture those fields; the request only has to carry them faithfully.
2. How do symptoms read as observations?
Symptoms follow, written as observations rather than conclusions. List the fault codes with their full text, the fault history with timing, whether the fault survives a power cycle, and what the machine was doing when it first appeared. The distinction matters because a conclusion closes the partner's thinking, while an observation invites a hypothesis you did not write down, which is exactly the value of raw evidence.

Diagram unavailable.
Include what was already tried, such as resetting parameters or swapping supply phases, and what happened after each attempt. Write the attempts in the order you tried them, because sequence matters when a fault changed behavior after a reset. An attempt that changed nothing is evidence too, and it saves the partner from recommending the same dead end.
The observations also set the tone of the whole request. A partner reading a dated, ordered list of events can weigh it; a partner reading a verdict has to unpack it first. You are not diagnosing for them, and the request works best when it makes that explicit: here is what was seen, here is what was tried, here is what nobody checked.
3. Why do environment and condition belong in the pack?
Environment and physical condition belong in the same request. Describe the cabinet heat, dust, and moisture the drive lived in, and note the state of the cooling fan plus any discoloration around the power terminals. Photographs of the power section and the terminal area carry more information than any written description of them, and they cost nothing to include.

Diagram unavailable.
These details can change what a partner checks first on the bench. A drive that lived in dust and heat for ten years is a different case from the same reference in a clean room, and the partner should know which one they are getting. Heat stress suggests one family of checks; conductive dust suggests another; both together suggest the terminals get looked at before the electronics.
The condition evidence also protects the commercial conversation. When the returned report mentions dirt or heat damage, a request that already documented the cabinet shows the condition was known and reported, not discovered as a surprise. The environment article in this series explains which observations carry weight; the request only has to carry them forward honestly.
4. What configuration evidence travels with the drive?
Attach the configuration evidence if the drive ever ran in the machine. The parameter backup, or failing that photos of the decisive parameter groups, lets the partner compare a returned unit's settings against the machine's known state. Without it, an exchange or repaired unit comes back on factory defaults and the tuning starts from zero.

Diagram unavailable.
Wiring photographs and motor data belong in the same pack, because the drive is only half of the circuit that failed. The motor data matters here too, since the partner may want to verify settings against the motor the drive will run. A pack that carries both sides of the link lets the partner answer questions that neither half could answer alone.
The configuration evidence also shortens the trip back. A unit that returns with its settings intact can be compared at the cabinet against the captured set instead of re-tuned, and the difference list from the backup article tells the commissioning crew exactly which values deserve attention. The backup was made while the drive ran; this is the moment it pays for itself.
5. How does the evidence steer the assessment?
The evidence steers what the partner expects to find, even though the bench test delivers the verdict. A history of overvoltage trips during deceleration points toward braking and load inertia, an undervoltage pattern points toward the supply, and a dead unit changes the test plan again. Each pattern suggests where the bench time goes first, which is what makes the assessment faster and the quote sharper.

Diagram unavailable.
A request that says only the drive is faulty throws all of that steering away. The difference in assessment time and quote quality between the two request types is real, though its size depends on the partner. What does not depend on the partner is the direction: evidence lets the reviewer start from your observations instead of rediscovering them.
You are not diagnosing for them; you are giving them a head start they can verify on the bench. The wording matters because a request that overreaches invites a reply that pushes back on your conclusions instead of engaging with your evidence. Observations stated plainly, with their limits marked, travel furthest.
6. How do repair and exchange quotes differ?
Repair and exchange differ on lead time, cost structure, and what comes back, and the right choice depends on facts your request helps establish. A repair returns the same unit, which preserves any revision-specific fit. An exchange supplies a different unit whose revision and options must be checked against the machine. Neither path has a predictable price or outcome, so treat every quote as dated evidence and compare like with like.

Diagram unavailable.
The offer versus stock article in this series covers how to label those claims, and the same discipline applies here. A repair quote describes one assessment of one unit on one date; an exchange quote describes an item a seller expects to hold. Mixing the two grades, or reading last month's quote as this month's price, is how recovery budgets go wrong.
Ask what each quote assumes. Repair quotes usually carry a scope that moves once the bench opens up, and exchange quotes usually carry conditions about the returned unit's state. Reading the assumptions is part of comparing the numbers, and the assumptions are exactly where a cheap option turns expensive.
7. What closes the loop after the unit returns?
For an exchange, reuse the sizing checklist instead of trusting the word equivalent. Supply class, output current, overload duty, control interfaces, and braking capability each get a line in the comparison, with the exchange unit's nameplate as the source for its side. An exchange that arrives missing an option, say a network card slot, can cost more in adaptation than it saved on the quote.

Diagram unavailable.
Keep the whole correspondence in the record, including the partner's questions and your answers. Their questions reveal which evidence was missing, and your answers document the state of the unit at handover. The comparison record also supports any warranty conversation later, because the condition at handover is written down by both sides in the same file.
When the unit comes back repaired or exchanged, note what was found and what was replaced, because that result feeds the next failure of the same reference. If a line in the comparison cannot be filled in, mark it unknown and ask the partner before accepting the unit. The intake decision is complete when the outcome sits on file alongside the request, and the fleet inherits both.
How the flow works
Key takeaways
- Send the full reference, revision, and serial number, with a nameplate photo attached.
- Report fault codes, history, and attempts as observations rather than a verdict.
- Include environment notes, condition photos, and the parameter backup in one pack.
- Run the sizing checklist on any exchange unit, and keep the partner correspondence on file.
Related pages
Editorial notes and sources
This preview is a bounded brief, not a reviewed technical article or a compatibility, stock, price, service, or safety claim.
Source ledger
Version: docs/product/comparison-and-recovery-model.md|Repair capability evidence required
- docs/product/comparison-and-recovery-model.md
- Repair capability evidence required
Workflow state
Status: draft / noindex
Unresolved: technical and commercial claims need attributable evidence
