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.

Editorial brief / publication gateDRAFT / NOINDEX

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.

A nameplate yields the full reference, revision and serial fields, and the attached photo makes the whole request searchable.
The flow covers what the request carries, not how the partner stores it. A replaced plate is recorded as such, and the new plate is photographed.

Enlarged system diagram

A nameplate yields the full reference, revision and serial fields, and the attached photo makes the whole request searchable.

The flow covers what the request carries, not how the partner stores it. A replaced plate is recorded as such, and the new plate is photographed.

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.

Fault events and ordered attempts combine into an observation pack that reports what happened without attaching a verdict.
The pack reports sequences and states. It does not include actuating tests, and attempts are recorded with their results, however small.

Enlarged system diagram

Fault events and ordered attempts combine into an observation pack that reports what happened without attaching a verdict.

The pack reports sequences and states. It does not include actuating tests, and attempts are recorded with their results, however small.

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.

Cabinet conditions and terminal photos form condition evidence that steers the first bench checks on the unit.
The evidence describes the environment the unit came from. It does not diagnose the failure, and the bench assessment remains the partner's work.

Enlarged system diagram

Cabinet conditions and terminal photos form condition evidence that steers the first bench checks on the unit.

The evidence describes the environment the unit came from. It does not diagnose the failure, and the bench assessment remains the partner's work.

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.

Parameter backup, wiring photos, and motor data combine into a configuration pack that makes a returned unit comparable rather than retuned.
The pack documents configuration, and the return comparison checks values against it. It does not transfer settings into a different drive.

Enlarged system diagram

Parameter backup, wiring photos, and motor data combine into a configuration pack that makes a returned unit comparable rather than retuned.

The pack documents configuration, and the return comparison checks values against it. It does not transfer settings into a different drive.

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.

Evidence patterns point the bench assessment toward braking, supply, or power stage checks, while an empty request starts from zero.
The patterns steer expectations, they do not replace the bench test. The partner's verification remains the source of the verdict.

Enlarged system diagram

Evidence patterns point the bench assessment toward braking, supply, or power stage checks, while an empty request starts from zero.

The patterns steer expectations, they do not replace the bench test. The partner's verification remains the source of the verdict.

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.

A repair quote and an exchange quote, both dated and labeled with their assumptions, feed one like-for-like comparison.
The comparison treats quotes as dated evidence, not fixed prices. Assumptions and conditions belong in the record next to the numbers.

Enlarged system diagram

A repair quote and an exchange quote, both dated and labeled with their assumptions, feed one like-for-like comparison.

The comparison treats quotes as dated evidence, not fixed prices. Assumptions and conditions belong in the record next to the numbers.

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.

An arriving exchange unit passes the sizing checklist and unknown lines get asked about, and the correspondence plus outcome close the file.
The checklist verifies the arriving unit against the machine, not against the quote's wording. The file records the outcome for reuse.

Enlarged system diagram

An arriving exchange unit passes the sizing checklist and unknown lines get asked about, and the correspondence plus outcome close the file.

The checklist verifies the arriving unit against the machine, not against the quote's wording. The file records the outcome for reuse.

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

Repair intake flow compiling identity, symptoms, environment, and configuration into a partner assessment, then dated quotes, then a recorded outcome with sizing check.
The evidence path from the failed drive through partner assessment to a recorded outcome, with the sizing check guarding any exchange.

Enlarged system diagram

Repair intake flow compiling identity, symptoms, environment, and configuration into a partner assessment, then dated quotes, then a recorded outcome with sizing check.

The evidence path from the failed drive through partner assessment to a recorded outcome, with the sizing check guarding any exchange.

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.
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

Return to the category hub