Error Codes: What They Tell You and What They Don't

How to use medical device error codes as clues without mistaking them for a diagnosis

Error codes are useful.

Published August 13, 2026 · Revised September 6, 2026

Back to Biomed Basics

What This Page Explains

This page covers:

The Simple Version

An error code usually means the device detected a condition outside what its software expected. It does not automatically mean the component named in the message is defective. A “flow sensor error,” for example, may only tell you that the device could not obtain a believable flow value. The cause could be a dirty or incorrectly installed sensor, a damaged cable, a blocked pneumatic path, missing supply, failed calibration, or the circuit that reads the sensor.

Use the code to identify the failed check, then troubleshoot the complete path that could produce that response. Preserve the exact code and wording, when it occurred, what the device was doing, installed accessories, recent service, and nearby events. Those details often matter more than the code number by itself.

Worked Example: Intermittent Motor Error

Suppose a pump logs a motor-position error only during high-rate operation. Before ordering a motor, check the service manual's code definition and event context. The controller may have commanded movement but failed to see the expected encoder change. Possible causes include mechanical binding, a slipping drive, an intermittent encoder cable, weak motor drive, excessive load, or a position sensor problem.

Reproduce the condition safely using the approved test setup and compare low- and high-load behavior. Review timestamps and related power or communication errors. Capture evidence before clearing logs. After correcting the root cause, rerun the applicable self-test and full performance verification; the absence of a code after one power cycle does not prove the repair.

The Device Knows What It Can Measure

A medical device only knows what its sensors and software tell it.

It does not always know why something is wrong.

Imagine a device expects:

24 VDC

but measures:

18 VDC.

It may generate:

Power Supply Error.

But the actual cause could be:

The device knows the voltage is wrong.

It may not know why.

Error Condition vs Root Cause

This distinction is extremely important.

Error Condition

What the device detected.

Root Cause

The underlying reason the condition occurred.

Example:

Error condition:

Battery Communication Lost.

Possible root causes:

Do not automatically make the first one your diagnosis.

Read the Exact Code

Do not troubleshoot:

It had some battery error.

Get the exact:

For example:

These may look similar but mean very different things:

Battery Low

Battery Not Recognized

Battery Communication Failure

Battery Temperature High

Battery Charging Error

Write down exactly what the device says.

Take a Picture When Appropriate

If facility policy allows and no patient information is exposed, documenting the exact screen can be useful.

That helps avoid mistakes such as:

I think it said E104.

when it actually said:

E140.

One digit can change the entire troubleshooting path.

Error Codes May Be Manufacturer-Specific

There is no universal meaning for:

E001.

One manufacturer may use it for:

Battery failure.

Another may use it for:

Processor error.

Another may not use it at all.

Always use the correct documentation for:

Do not rely on a code from a different device because it looks similar.

Software Version Can Matter

Manufacturers sometimes change:

A manual for software version 2 may not match a device running version 7.

Verify applicability.

Active Errors

An active error is happening now.

That is often useful because you can test the device while the condition exists.

For example:

Gas Supply Pressure Low.

While the error is active, you can measure:

That gives you real-time evidence.

Historical Errors

A historical error occurred earlier.

It may no longer be active.

These are useful for intermittent failures.

Example:

Staff reports random reboot.

Current device:

Works perfectly.

Error history shows:

Internal 5 V Rail Low

three times around the reported events.

That is valuable information.

But Historical Errors Need Context

A log may contain hundreds of old entries.

Do not assume every stored code relates to the current complaint.

Look at:

A two-year-old error is usually less relevant than one that occurred five minutes before the failure.

Error Frequency Matters

One error once:

Interesting.

Same error fifty times:

More interesting.

Repeated faults may indicate:

Frequency can help establish patterns.

Sequence Matters

Sometimes the first error is more useful than the last.

Example:

10:14:02 — Fan Failure

10:14:18 — Temperature High

10:14:24 — Processor Shutdown

If you only focus on:

Processor Shutdown

you may replace the wrong part.

The sequence suggests:

Fan stopped.

Temperature rose.

Processor shut down to protect itself.

The shutdown may be the consequence, not the cause.

Cascade Errors

One failure can generate many secondary errors.

Example:

Power rail fails.

Then:

You now have five error codes.

That does not necessarily mean five components failed simultaneously.

Look for the common upstream problem.

First Failure Can Be Important

When several errors appear together, look for:

The first failure may have triggered the rest.

Not always.

But it is worth investigating.

Startup Errors

Startup errors can tell you where initialization stopped.

A simplified boot sequence might be:

  1. Power rails stabilize.
  2. Processor starts.
  3. Memory test.
  4. Modules initialize.
  5. Sensors initialize.
  6. Application loads.

If startup consistently stops at:

Module Initialization Failure

you have narrowed the problem.

Self-Test Codes

Some devices generate codes during:

These can be especially useful because the manufacturer often provides a specific troubleshooting tree for them.

Follow it.

Do Not Just Clear the Error

Sometimes technicians clear an error just to see if it comes back.

That can be useful later.

But first:

Once cleared, some information may be harder to retrieve.

Rebooting Can Clear Useful Evidence

Power cycling may:

For routine repairs, rebooting may be fine.

For intermittent or serious events, preserve evidence first.

Look Up the Full Troubleshooting Entry

Do not stop at:

E123 — Flow Sensor Error.

The manual may continue:

Possible causes:

  1. Sensor not seated.
  2. Sensor contaminated.
  3. Cable damaged.
  4. Calibration required.
  5. Interface board failure.

Those details matter.

Troubleshooting Tables Have Order for a Reason

Manufacturers often arrange checks from:

toward:

If the table says:

  1. Reseat cable.
  2. Test sensor.
  3. Run calibration.
  4. Replace interface board.

do not start at step four.

Part Replacement in a Manual Is Not Always Confirmation

A service manual may say:

If previous steps do not resolve fault, replace main board.

That means:

The main board is the manufacturer's next repair step after other causes are excluded.

It does not necessarily mean:

The error code itself proves the main board is bad.

Important distinction.

Error Codes Can Be Very Strong Evidence

Sometimes a code is extremely specific.

Example:

A processor performs an internal memory test.

A particular memory block fails repeatedly.

Manual states:

Replace processor board.

If the diagnostic is specifically designed to test that hardware, the code may be strong evidence.

Not every error is equally vague.

Internal Monitoring Can Be Specific

Some devices directly monitor:

An error such as:

Fan Speed = 0 RPM

while the fan receives proper voltage may strongly point toward the fan.

Context determines the strength of the evidence.

Sensor Errors Are Often Less Specific

Sensors exist in a chain.

Example:

Physical condition

↓

Sensor

↓

Cable

↓

Connector

↓

Input electronics

↓

Software

If the device says:

Sensor Error

any part of that path may be responsible.

Communication Errors

Messages such as:

Module Communication Failure

may involve:

The device knows:

I cannot communicate with this module.

It may not know why.

“Not Recognized” Errors

A device may show:

Accessory Not Recognized.

Possible causes:

Do not immediately assume the accessory is defective.

Power Errors

Power-related messages may include:

Interpret each separately.

If:

Battery Low

occurs after six hours of normal battery operation, that may simply be expected.

If it occurs immediately after unplugging, that is different.

Context matters.

Environmental Conditions Can Trigger Errors

A perfectly good device can alarm because the environment is wrong.

Examples:

The code may be correct.

The device may be healthy.

User Setup Can Trigger Errors

Examples:

Do not assume every error requires a repair.

Sometimes the device is protecting the user from incorrect setup.

Compare With Known-Good Equipment

If you are unsure what a code means, comparison can help.

Example:

Suspect device produces:

Sensor Calibration Failed.

Known-good device with same sensor:

Passes.

Now sensor may be less likely.

If suspect sensor fails on both devices:

Sensor becomes more likely.

Known-good testing strengthens the code interpretation.

Reproduce the Error

A repeatable error is much easier to troubleshoot.

If you can make:

E145

appear every time the motor starts, you have a useful pattern.

Now test what changes during motor startup.

Intermittent Errors

For intermittent problems, ask:

The code plus the condition can be more useful than the code alone.

Look at the Data Behind the Error

Service mode may display raw values.

Example:

Error:

Temperature Sensor Fault.

Service diagnostics:

Sensor temperature = -40°C.

That extreme value may suggest:

The raw value gives you more information.

Invalid Values Can Be Clues

Sensors often produce recognizable failure values.

An open circuit might appear as:

Knowing how the circuit behaves can help interpret the error.

Error Code After Repair

After repair:

Clear or acknowledge errors according to manufacturer procedure.

Then recreate the operating conditions.

Confirm:

Do not stop at:

Error message gone.

A Missing Error Does Not Prove a Repair

Suppose the error appears once per week.

You replace something.

Run device for ten minutes.

No error.

That is weak evidence.

Match the test to the failure pattern.

Intermittent problems need appropriate observation before they are documented as unable to duplicate.

Document the Exact Finding

Weak:

Had error. Fixed.

Better:

Unit repeatedly displayed E214 “Battery Communication Failure” during operation on battery. Error reproduced with original battery and remained with known-good battery. Inspected battery connector and found intermittent contact at harness. Repaired connection and repeated battery operation/movement test without recurrence.

That is a useful technical record.

Do Not Write the Code as the Diagnosis

Weak:

E214.

That does not tell the next technician what actually failed.

Better:

E214 Battery Communication Failure caused by intermittent battery harness connection.

Now the code and root cause are both documented.

When Calling the Vendor

Give technical support:

Instead of:

I'm getting a sensor error.

say:

Unit consistently generates E324 during flow calibration. Error remains with two known-good sensors and calibration fails at the same step each time.

That is much easier to support.

Real-World Example: Flow Sensor Error

Ventilator:

Flow Sensor Error.

First thought:

Bad sensor.

Test:

Original sensor fails.

Known-good sensor also fails.

Original sensor works on another ventilator.

Inspect connector.

Bent contact found.

The code accurately identified the subsystem.

It did not identify the failed component.

Real-World Example: Battery Error

Monitor:

Battery Not Recognized.

Known-good battery:

Same error.

Original battery:

Works in another monitor.

Battery contacts:

One pin pushed back.

Again:

The message told you the communication path was failing.

Not necessarily the battery.

Real-World Example: High Temperature Error

Device reports:

Internal Temperature High.

Possible causes:

If the fan is stopped and temperature rises, the temperature error is doing exactly what it should.

Do not replace the temperature sensor.

Real-World Example: Network Error

Medical device says:

Server Unavailable.

Device:

Server:

Offline.

The medical device is not broken.

The error correctly describes the unavailable destination.

Real-World Example: Multiple Errors After Power Failure

Device log:

12:00:01 — 12 V Rail Low

12:00:02 — Sensor Communication Lost

12:00:02 — Display Communication Lost

12:00:03 — System Reset

Do not diagnose:

all at once.

Investigate the power rail first.

Common Mistakes

Treating the Code as the Failed Part

It may only identify a condition.

Recording the Code Incorrectly

Get exact wording.

Ignoring Timestamp

History matters.

Looking Only at the Last Error

Earlier faults may have caused it.

Clearing Errors Too Early

Preserve evidence.

Ordering the First Part Listed

Follow the troubleshooting path.

Ignoring External Conditions

The device may be alarming correctly.

Assuming No Code Means No Problem

Not every failure is detectable.

A Useful Troubleshooting Framework

When you see an error code, ask:

What condition did the device detect?

Then:

What does the device actually measure to detect that condition?

Then:

What components could affect that measurement?

Then:

What test separates those possibilities?

That turns an error code into a troubleshooting path.

Another Useful Question

Ask:

Could this code be a consequence of something upstream?

If several systems fail at once, look for a common cause.

Power.

Communication.

Temperature.

Configuration.

Do not automatically replace every component that throws an error.

What Did You Actually Prove?

Suppose the log says:

Flow Sensor Communication Lost.

You proved:

The device recorded loss of communication with the flow-sensor system.

You did not automatically prove:

The flow sensor itself failed.

Keep your conclusion the same size as your evidence.

Final Thoughts for Biomeds

Error codes are incredibly useful.

But treat them like clues.

A good code can tell you:

Sometimes it may even identify the exact failed hardware.

But do not assume that.

Read the full message.

Look at the sequence.

Review the manual.

Reproduce the condition.

Use known-good components.

Measure what you can.

Then determine what actually caused the device to generate the error.

The goal is not to make the error disappear.

The goal is to understand why it appeared.

— Jake

Important Note

Error-code definitions and diagnostic behavior vary by manufacturer, model, hardware revision, and software version. Always use current applicable manufacturer service documentation and follow facility procedures, required verification steps, and your authorized service scope when troubleshooting medical equipment faults.

Related Biomed Basics

Back to Biomed Basics