Scope of this technical record
ATV61 / ATV71 OCF overcurrent route for users deciding whether the event is caused by motor setup, high inertia, mechanical blockage, brake release, cable/motor condition, current feedback or the inverter output stage.
Do not use repeated reset-and-run attempts as a diagnostic method. Secure the machine, verify discharge before internal work and prove the motor/cable boundary before treating OCF as a power-board failure.
OCF technician decision route
OCF is routed through setup and machine evidence before current-feedback or output-bridge repair.
ATV61 / ATV71 OCF timing image
Service decision matrix
OCF needs a timing split before a part decision. The page separates settings, load and cable evidence from drive-side current hardware.
| Observed situation | Decision needed | Evidence to collect |
|---|---|---|
| At first PWM | Setup or output path | Motor data, boost/current limit and cable evidence |
| During acceleration | Ramp/load/brake | Acceleration time, load state and brake release proof |
| After repair | Driver/current feedback | Previous module history and channel evidence |
OCF is a current event, not a part number
OCF means the drive has reached a hardware current limitation or equivalent overcurrent boundary. The fault code alone does not identify the failed part. In real service the same OCF label can come from a wrong motor nameplate entry, aggressive acceleration, a locked fan or pump, a hoist brake that is still applied, a shorted cable, biased current feedback or an output bridge that has already been damaged.
The page is built around the technician's actual decision: can this be corrected by settings or machine-side work, or has the drive-side current path become suspect? The answer comes from trip timing and evidence, not from the code alone.
Timing decides the first test
Record the first occurrence before resetting the drive. A technician should know whether OCF appears at power-up, on run command, at first PWM, during the acceleration ramp, at a specific frequency, at brake release, during a load step, or after previous power-stage work.
OCF timing and first diagnostic boundary
| OCF timing | Likely first boundary | Evidence that moves the case forward |
|---|---|---|
| At run command / first PWM | Motor data, short output path, excessive boost | Motor nameplate comparison, cable/motor isolation, parameter snapshot |
| During acceleration | Ramp too short, high inertia, machine load | Current trend, acceleration time, load state, brake release status |
| Only after brake should release | Mechanical brake or load remains held | Brake coil voltage, release timing, shaft/load movement evidence |
| At a repeatable load point | Process load or current feedback | Load condition, output current balance, fault queue |
| After module replacement | Unresolved driver/current-sense or external cause | Pre-power driver evidence and motor/cable proof before another run |
Parameter and machine checks before electronics work
Schneider's public OCF guidance specifically points to motor-control settings matching the motor nameplate, excessive inertia or load, and mechanical blockage. Those are not minor checks; they are the first way to avoid replacing a good drive or destroying a repaired output stage.
Compare motor frequency, voltage, current and speed with the real motor. Then check acceleration time, current limit, control mode, torque boost, flying-start/catch-on-the-fly use and any application-specific brake sequence. A drive on a hoist, conveyor or pump can trip OCF because the machine is asking for torque faster than the system can deliver safely.
- Nameplate data entered in the motor-control menu matches the installed motor
- Acceleration time is realistic for the load inertia
- Mechanical brake or valve is not holding the load during acceleration
- Motor cable and output terminals show no moisture, tracking or loose strands
- No output capacitors or unsupported switching devices are connected on the VFD output
When OCF becomes a drive-side repair case
OCF becomes a drive-side case only after external causes are no longer credible. If the trip remains with the output path proven under qualified procedure, the investigation moves inward: current-feedback channels, gate-drive permission, phase output static checks, power module condition and evidence of previous board work.
The dangerous case is a replaced IGBT or power board with no root-cause evidence. If a current sensor is biased, a gate-driver channel is weak, or the motor cable fault was never corrected, the new module may fail immediately. A repair request should therefore include motor/cable proof and a previous-repair history, not only a photograph of the damaged semiconductor.
Support request checklist for OCF
A high-quality OCF request lets a service engineer decide whether the next response should be settings help, field investigation, workshop repair or replacement planning. Without this evidence, the safest answer is to gather data rather than sell a board.
- Exact ATV type code and motor nameplate photos
- Fault timing and first fault after reset/power cycle
- Acceleration/deceleration settings and load description
- Brake release, jam, blocked pump/fan or conveyor load evidence
- Motor/cable insulation and output terminal evidence
- Previous module, power board or control board replacement details
Field record checklist
- OCF timing
- Motor nameplate and motor-control data
- Ramp/load/brake evidence
- Motor/cable proof
- Current-feedback or output-stage suspicion
- Repair history
Technical basis and reference documents
This is an independent editorial technical reference. Original manufacturer documentation remains controlling for installation, repair and commissioning decisions.
Used to anchor OCF around hardware current limitation, motor data, high inertia, excessive load and mechanical blockage.
Used to anchor SCF1 around drive output short/grounding, motor cable checks, motor insulation and transistor test routing.
OEM programming and fault-reference context for Altivar 71 diagnostic pages.
OEM installation and wiring context for safe output and motor-cable evidence collection.
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