How to Read YS620 Fault History and Operating Data for Faster Diagnosis

YS620 diagnosis should use the d-group evidence captured around the event. The manual lists recent fault types and snapshot values including fault frequency, current, bus voltage, internal temperature, fault time and feedback pressure. Combining those values with the motor plate, pump condition, supply measurements, wiring and event timeline is more reliable than resetting the drive and guessing from one alarm code.

Why This Application Needs Pump-Specific Engineering

A pump VFD alarm is a classification, not a complete root cause. Overcurrent during acceleration, for example, can involve ramp time, motor wiring, mechanical load or inappropriate control data. Undervoltage can come from the incoming supply or another large load starting on the same grid. A pressure-related alarm can reflect real hydraulics, sensor scaling or a broken feedback circuit. The YS620 monitoring group preserves useful context, but service staff must collect it before initialization or uncontrolled parameter changes. A disciplined evidence pack also makes support across countries and time zones much faster.

Engineering Decisions and Evidence

Preserve the alarm sequence

YS620 monitoring includes first, second and third fault-type records rather than only the message currently displayed.

Evidence to collect: d-13, d-14 and d-15 values photographed or transcribed before reset.

Risk if ignored: The visible alarm may be a consequence rather than the initiating event.

Engineering decision: Build a timeline starting with the earliest credible event.

Read frequency at the fault

d-16 records fault frequency, which separates starting, low-speed and full-duty events.

Evidence to collect: Fault frequency compared with commanded mode and pump duty.

Risk if ignored: A diagnosis based on normal running may miss an acceleration or sleep transition problem.

Engineering decision: Reproduce only under a safe plan at the same operating phase.

Compare fault current with the motor

d-17 provides current at the event, but interpretation requires the motor plate and drive rating.

Evidence to collect: Fault current, rated motor current, normal baseline and load state.

Risk if ignored: A raw current number without units and context can lead to an incorrect overload conclusion.

Engineering decision: Check electrical and hydraulic causes before changing protection values.

Use bus voltage to investigate supply events

d-18 records bus voltage at the fault and can support overvoltage or undervoltage analysis.

Evidence to collect: Bus value, incoming line voltage, grid events and other loads starting at the same time.

Risk if ignored: Supply dips or regenerative events may be missed by a slow handheld measurement.

Engineering decision: Correlate VFD evidence with a suitable power-quality investigation when necessary.

Use internal temperature as evidence

d-19 records internal temperature around the fault.

Evidence to collect: Ambient, fan condition, air passage, carrier setting, load and prior run time.

Risk if ignored: Cleaning the drive may not solve overheating caused by enclosure recirculation or overload.

Engineering decision: Inspect airflow and thermal environment, then compare with a healthy baseline.

Connect pressure to the event

d-21 records feedback pressure at the fault, helping separate hydraulic demand from electrical trips.

Evidence to collect: Feedback pressure compared with a trusted gauge and target at the event.

Risk if ignored: A broken or mis-scaled sensor can imitate a real low- or high-pressure condition.

Engineering decision: Validate the feedback channel before changing pump limits.

Use fault time and operating hours

d-20 and accumulated time records help determine whether events repeat after a similar duration.

Evidence to collect: Fault time, power-on hours, running hours and maintenance history.

Risk if ignored: Intermittent thermal or source problems may look random without elapsed-time context.

Engineering decision: Look for patterns after startup, peak demand, cleaning or seasonal temperature change.

Change one hypothesis at a time

Several simultaneous parameter edits destroy the evidence needed to identify cause.

Evidence to collect: Baseline backup, one approved change, new readings and result.

Risk if ignored: A temporary improvement cannot be attributed and may weaken protection.

Engineering decision: Restore the validated baseline when a tested hypothesis is rejected.

Verification Workflow

Stage	Action	Acceptance evidence
Freeze	Do not initialize or overwrite evidence	Fault records preserved
Capture	Read d-13 through d-21 as relevant	Snapshot complete
Context	Add motor, pump and demand state	Event timeline built
Classify	Separate electrical, hydraulic and feedback paths	Test hypotheses ranked
Test	Change one variable safely	Cause supported or rejected
Close	Record repair and new baseline	Repeatability verified

Information Buyers Should Send With the RFQ

• Exact ys620 model and parameter revision
• Motor plate and pump curve
• D-13 through d-21 fault evidence
• Normal current, frequency and pressure baseline
• Incoming voltage before and during the event if available
• Sensor signal, range and gauge comparison
• Photos of power and motor terminals
• What changed before the first failure

Example evidence matrix

For an acceleration overcurrent, combine the fault code with d-16 frequency and d-17 current, then check acceleration time, motor data, wiring and pump mechanical state. For overheating, combine d-19 temperature with ambient, current, fan and airflow. For pressure alarms, compare d-21 with a gauge and source condition. The same monitoring values have different meaning for different alarms, so the code and operating phase must stay linked.

Distributor support workflow

A distributor can collect a standardized form before forwarding a case: product label, motor plate, application, alarm sequence, snapshot values, wiring images, parameter changes and a short video only when safe. Ausenist then receives searchable evidence rather than disconnected chat messages. This improves response quality and helps train local partners as pump-VFD specialists without encouraging unauthorized repairs.

Closing the case professionally

After correcting the cause, repeat the operating state that produced the alarm within an approved test. Record normal current, frequency, pressure, voltage and temperature. Update maintenance findings and parameter revision, but preserve the original evidence. A case is not closed merely because the reset succeeded; it is closed when the root cause is supported and normal operation is demonstrated.

Frequently Asked Questions

Should I reset the YS620 before contacting support?

Capture the alarm sequence and monitoring values first. A reset can remove the most useful context.

Does high fault current prove a motor problem?

No. Wiring, ramp, load, pump blockage and control data can also contribute. Use the complete event.

Can feedback pressure prove the sensor is correct?

No. Compare it with an independent trusted gauge and verify signal scaling.

Why collect bus voltage if line voltage looks normal now?

The disturbance may have been brief. Snapshot data can help identify the event, although detailed power analysis may still be needed.

When should Ausenist be contacted?

Escalate when alarms repeat, evidence conflicts, hardware faults appear or a safe test cannot isolate the cause.

Ask Ausenist for an Application Review

Send Ausenist the YS620 model, alarm sequence, d-group snapshot, motor plate, pump duty, gauge comparison, supply readings and event history. Our specialists can use this evidence to separate electrical, hydraulic, feedback and environmental causes.