If a Test Fails: The Machine Event Snapshot

You ran the Confidence Check.

Something didn’t pass.

Maybe the result is Yellow.

Maybe it is Red.

Either way, you have reached the point where you may need help determining what happens next.

This is where many technical-support conversations begin with something like:

“I bumped my machine and now it doesn’t seem right.”

That’s understandable.

But it doesn’t give the technician much to work with.

What hit what?

Which direction was the machine moving?

What tooling was involved?

Did anything visibly move?

Does the machine home?

Does the spindle run normally?

Does the ATC work?

What test failed?

Did it fail once or repeatedly?

What changed from the Healthy Machine Baseline?

By the time those questions have been answered, a large part of the support call may have been spent simply reconstructing what happened.

We can do better.

We need a:

Machine Event Snapshot

The Machine Event Snapshot is a short record of:

What happened.

What you found.

What you tested.

What passed.

What failed.

What changed from the Healthy Machine Baseline.

Its purpose is simple:

Give technical support the information needed to help you get up and running as quickly as possible.

The Snapshot Begins at the Moment of the Event

Think back to the beginning of this series.

One of the first things we asked was:

What kind of bump was it?

That information matters now.

Start with the event itself.

Record:

Date and time:

Machine:

Operator:

Program or job being run:

What was moving?

What made contact?

Where did contact occur?

What happened immediately afterward?

Don’t worry about diagnosing the cause yet.

Describe what happened as accurately as you can.

Describe the Contact Path

Remember our earlier rule:

Where the contact occurred helps determine what should be checked next.

Was it:

Be specific.

Instead of:

“The spindle hit something.”

write:

“During an X-positive move, the collet nut contacted the top of the clamp.”

That tells us much more.

Record What Was Moving

Direction matters.

If you know it, record:

Also record whether the machine was:

The objective is to reconstruct the event without relying on memory several days later.

Don’t Rate the Event by the Noise

We established this earlier, but it belongs in the Snapshot philosophy too.

Don’t write:

“It was a terrible crash.”

That tells technical support how the event felt.

It doesn’t tell them what happened.

Instead, describe the physical event.

For example:

“The 1/4-inch cutter contacted an aluminum clamp during a rapid move. The cutter broke. The holder did not visibly contact the clamp.”

Or:

“The tool holder contacted the fixture before the cutter reached the material.”

Those descriptions are much more useful.

Record facts first.

Interpretation can come later.

Photograph the Scene Before You Change It

If it is safe to do so, photograph the machine before cleaning up the event.

Take pictures of:

Take a wider photograph showing the overall setup.

Then take close-ups.

A close-up may show damage.

The wide photograph shows how everything was related when the event occurred.

Both can matter.

Photograph Witness Marks

Witness marks can tell the story of the collision.

A mark on a clamp may reveal:

A spoilboard mark may reveal:

A mark on a fixture may reveal the actual contact path.

Don’t clean those clues away before documenting them.

The evidence may be temporary.

The photograph preserves it.

Save the Alarm Information

If the controller displayed an alarm or error message, preserve it.

Take a photograph or screenshot where practical.

Record:

Don’t rely on remembering the message later.

“It said something about the servo.”

is much less useful than the actual alarm information.

Don’t Clear Information Before Recording It

The natural reaction after an alarm is often:

Reset.

Clear.

Try again.

Before doing that, ask whether the information on the screen might help explain the event.

Record it first.

Then follow the appropriate recovery procedure.

The same principle applies throughout the Machine Event Snapshot:

Preserve useful evidence before changing the condition.

Identify the Tooling Involved

Record the complete tooling assembly involved in the event.

Include:

If the cutter broke, say so.

If the cutter slipped in the collet, record that.

If the holder contacted something, identify and quarantine it.

If you don’t know whether a holder was affected, record that uncertainty.

Don’t convert:

Unknown

into:

Okay

simply because no damage is immediately visible.

Preserve Questionable Tooling

If tooling was involved in the collision, don’t put it back into normal production before its condition is understood.

Label questionable components.

For example:

BUMP — CHECK BEFORE USE

Set them aside.

If technical support asks which holder was involved, you want to know exactly which holder it was.

This is another reason the known-good diagnostic holder is so valuable.

It allows testing to continue, where appropriate, without reintroducing the questionable component.

Record the Workholding

The clamp or fixture may be central to understanding the event.

Record:

If the clamp has a witness mark, photograph it.

If the workpiece moved, don’t automatically assume the machine lost position.

The workpiece may have moved relative to the machine.

That distinction matters.

Record the Setup Information

Sometimes the machine is blamed for information that was wrong before Cycle Start.

Record the important setup details where relevant:

We’re not trying to prove that the operator made a mistake.

We’re trying to understand the event.

The correct question is:

What information did the machine have when the event occurred?

Now Record What You Inspected

After documenting the original event, summarize the visual inspection.

For example:

Visual Inspection

Cutter: Broken / Damaged / No visible damage

Holder: No visible damage / Questionable / Damaged

Collet: Clean / Contaminated / Damaged / Replaced

Spindle taper: Clean / Contaminated / Visible concern

Clamp: Moved / Damaged / Witness mark / Normal

Fixture: Moved / Damaged / Normal

Workpiece: Moved / Damaged / Normal

Dust shoe: Normal / Contacted / Damaged

ATC: Normal visually / Concern noted

Cables and hoses: Normal / Concern noted

The objective is a quick summary.

Detailed notes can follow where necessary.

Record What You Cleaned or Changed

This is important because every change affects the diagnostic chain.

Record things such as:

If you changed something, record it.

Otherwise, later you may forget which test was performed before or after the change.

Record the Confidence Checks

Now summarize the tests you’ve already performed.

A simple Pass / Changed / Not Tested format works well.

Homing

Result: Pass / Changed / Not Tested

Notes:

X-Axis Motion

Result: Pass / Changed / Not Tested

Notes:

Y-Axis Motion

Result: Pass / Changed / Not Tested

Notes:

Z-Axis Motion

Result: Pass / Changed / Not Tested

Notes:

Rotary or Vertical System

Result: Pass / Changed / Not Applicable / Not Tested

Notes:

Record the Spindle Check

Spindle

Warm-up: Normal / Changed / Not Tested

Sound: Baseline / Changed

Vibration: Baseline / Changed

Speed behavior: Baseline / Changed

Temperature behavior: Baseline / Changed / Not Measured

Notes:

Avoid vague descriptions where possible.

Instead of:

“Spindle sounds bad.”

write:

“New rhythmic clicking begins near 12,000 RPM and repeats each time the speed passes that point.”

Specific observations are easier to investigate.

Record the ATC Check

For an ATC machine, summarize:

Tool changes completed:

Positions tested:

Holder return: Normal / Changed

Holder pickup: Normal / Changed

Seating: Normal / Changed

Clamp/release: Normal / Changed

Cone-cleaning air blast: Normal / Changed

Tool identification: Correct / Incorrect

Air system: Normal / Changed

Notes:

If only one position is questionable, identify it.

For example:

“Positions 1–9 operate normally. Position 10 produces repeatable holder contact during return.”

That is very useful information.

Record the Diagnostic Program Results

Now summarize the cuts you made.

Script Test

Baseline / Changed / Not Run

Notes:

Square

Baseline / Changed / Not Run

Notes:

Circle

Baseline / Changed / Not Run

Notes:

Pocket and Plug

Baseline / Changed / Not Run

Fit:

Surfacing Test

Baseline / Changed / Not Run

Notes:

Other Diagnostic Program

Program:

Result:

Again, don’t run tests simply to fill every blank.

If a Red condition told you to stop earlier, write:

Not tested — testing stopped because of Red condition.

That is the correct answer.

Record Precision Measurements Only If You Took Them

If the evidence led to precision measurement, record the results.

Runout

Measurement location:

Tooling used:

Reading:

Healthy Baseline:

Repeated: Yes / No

Return-to-Position

Axis:

Reference:

Approach direction:

Number of repetitions:

Results:

Healthy Baseline:

Tram

Measurement procedure:

Result:

Healthy Baseline:

Other Measurement

What was measured:

Why:

Result:

Baseline:

Notice the question:

Why?

That’s intentional.

We don’t want a page full of numbers nobody remembers the reason for measuring.

Record the Pattern, Not Just the Worst Number

Suppose the X return test produced:

Test 1: +.001

Test 2: +.006

Test 3: +.002

Test 4: +.007

Test 5: +.001

Don’t report:

X return error = .007

That loses useful information.

Report the sequence.

The variation may be more important than the largest number.

Likewise, if five tests all return approximately the same changed value, record that.

Repeatability tells technical support something about the nature of the problem.

Compare Everything With the Healthy Baseline

This is where the Snapshot becomes much more powerful than a conventional crash report.

We’re not merely describing today’s condition.

We’re comparing it with a known healthy condition.

For every important change, ask:

What did the machine normally do?

and

What is it doing now?

For example:

Healthy Baseline: Script engraving smooth through all curves.

After Event: Repeatable flat spot appears in the same section of the letter on three tests.

Or:

Healthy Baseline: Pocket-and-plug fit requires light hand pressure.

After Event: Plug now drops freely into pocket on two repeated tests using known-good tooling.

That comparison gives the observation meaning.

Separate Facts From Conclusions

This is another valuable habit.

Fact

The holder contacted the fixture.

Conclusion

The spindle is damaged.

Those are not the same thing.

Fact

The circle measures differently in X and Y.

Conclusion

The gantry is out of square.

Again, not the same thing.

Fact

The spindle sounds different at one speed.

Conclusion

The bearings are damaged.

Not necessarily.

Record the facts.

Let the evidence—and when appropriate, technical support—help determine the cause.

Don’t Diagnose for Technical Support

You don’t need to solve the problem before calling for help.

That’s the reason you’re calling.

Your job is to provide good evidence.

A statement such as:

“I think the gantry is bent.”

may unintentionally send the troubleshooting process in the wrong direction.

A statement such as:

“The square diagonals now differ from the Healthy Baseline, and the result repeated on three cuts using known-good tooling.”

is much more useful.

Describe what you know.

Distinguish it from what you suspect.

Include Photos and Video

If the issue involves something visible or audible, include supporting media where practical.

Useful examples include:

A short video can sometimes communicate a motion or sound problem much more effectively than several paragraphs.

Keep Videos Short and Focused

Don’t send a twenty-minute video of the entire machine running and expect someone to find the problem.

Capture the behavior you’re concerned about.

For example:

“This 20-second video shows Tool Position 7 returning normally, followed by Tool Position 8 making the contact I’m concerned about.”

That’s useful.

The same principle applies to photographs.

Show the technician what matters.

Identify What Has Already Passed

This is just as important as identifying what failed.

Suppose:

Technical support doesn’t necessarily need to begin by investigating every system on the machine.

The passed tests have already narrowed the problem.

That’s one of the greatest values of the Confidence Check.

What passed is evidence too.

Don’t Keep Testing After Red

If you encountered a Red condition, don’t continue running tests just to make the Snapshot more complete.

Write:

Testing stopped at this point because continued operation could cause additional damage or create an unsafe condition.

That is useful information.

A complete Snapshot does not mean every box has to contain a measurement.

Sometimes the most important entry is:

STOPPED HERE.

Build the Support Summary

At the top of the completed Snapshot, create a short summary.

Something like:

Machine Event Summary

Event: Cutter contacted clamp during X-positive rapid movement.

Visible Damage: Cutter broken; clamp marked; no visible spindle or holder damage.

Tooling Action: Cutter discarded. Impacted holder quarantined. Known-good holder and cutter installed for subsequent approved tests.

Checks Passed: Visual inspection, homing, X/Y/Z motion, spindle, ATC.

Test That Failed: Square test shows repeatable diagonal change from Healthy Baseline.

Measurement: X return agrees with baseline. Y return shows repeatable change across five tests.

Current Status: Red — testing stopped pending technical support.

Photos/Video: Collision scene, clamp witness mark, damaged cutter, square samples, indicator setup.

Now technical support can understand the situation in a minute or two.

The detailed information remains available below.

The Snapshot Should Travel With the Support Request

If you’re contacting technical support electronically, send the Snapshot with:

If you’re calling by phone, have the Snapshot in front of you.

Now when the technician asks:

“Does the machine home normally?”

you don’t have to answer:

“I think so.”

You can look at the record.

Update the Snapshot During Troubleshooting

The Machine Event Snapshot doesn’t have to stop when technical support becomes involved.

Add:

Now the Snapshot becomes a complete record of the event.

That record may become valuable months or years later.

Record the Final Resolution

When the problem has been identified, write down what actually caused it.

For example:

Cause: Cutter slipped in collet.

Correction: Collet replaced and tooling correctly assembled.

Or:

Cause: ATC fork shifted during collision.

Correction: Fork position corrected according to service procedure and all tool positions retested.

Or:

Cause: Workpiece moved during machining.

Correction: Workholding method revised.

This closes the diagnostic loop.

We began with an event.

We gathered evidence.

We identified the cause.

We corrected it.

We verified the machine.

Now we know what happened.

Don’t Throw the Snapshot Away When the Machine Is Fixed

Save it in the machine history.

Why?

Because machine events can teach us something.

Suppose a similar event happens two years later.

Now you have a previous record.

Or perhaps several Snapshots reveal that collisions repeatedly occur around the same:

Now we have identified more than a machine problem.

We have identified a process problem.

And that leads directly to prevention.

The Snapshot Is the Bridge Between After the Bump and Before the Bump

This is where our two systems connect.

After the Bump asks:

What happened to the machine, and is it healthy?

Before the Bump asks:

What can we change so this event is less likely to happen again?

The Machine Event Snapshot connects those questions.

Once the machine is back in service, review the Snapshot and ask:

What simple change could prevent this event from happening again?

Maybe the answer is:

Now the bump has produced something useful.

It has improved the system.

Don’t Turn the Snapshot Into Paperwork

There is a danger here.

We could build a ten-page form with fifty measurements and hundreds of boxes.

Then nobody would use it.

The Snapshot should capture the information needed to understand the event.

Nothing more.

Most events should fit on a concise form with supporting photographs, test results, and notes when necessary.

The goal is not documentation for its own sake.

The goal is:

Faster understanding.

Better technical support.

Better decisions.

Better prevention.

A Practical Machine Event Snapshot

A simple form could contain these sections:

1 — Event

Date:

Machine:

Operator:

Program:

What was moving?

What made contact?

Where did contact occur?

What happened immediately afterward?

2 — Evidence

Visible damage:

Witness marks:

Alarm or error:

Photos taken:

Video taken:

3 — Tooling and Setup

Tool number:

Cutter:

Holder:

Collet:

ATC position:

Work offset:

Workholding:

Anything moved?

4 — Actions Taken

Tooling quarantined:

Tooling replaced:

Cleaning performed:

Setup corrected:

Other changes:

5 — Confidence Checks

Visual Inspection: Pass / Changed / Not Tested

Homing: Pass / Changed / Not Tested

Axis Motion: Pass / Changed / Not Tested

Spindle: Pass / Changed / Not Tested

ATC: Pass / Changed / Not Tested

Script Test: Baseline / Changed / Not Run

Square: Baseline / Changed / Not Run

Circle: Baseline / Changed / Not Run

Pocket and Plug: Baseline / Changed / Not Run

Surfacing: Baseline / Changed / Not Run

6 — Measurements

Measurement:

Baseline:

Current result:

Number of repetitions:

Repeatable: Yes / No

7 — Decision

GREEN — Return to Work

YELLOW — Continue Investigation

RED — Stop and Contact Support

Reason:

8 — Technical Support

Date contacted:

Technician:

Additional tests requested:

Findings:

Actions taken:

9 — Resolution

Cause:

Correction:

Verification performed:

Machine returned to service:

10 — Prevention

What simple change could prevent this event from happening again?

Action:

Person responsible:

Completed:

The Snapshot Creates Institutional Memory

There is one final benefit.

A Machine Event Snapshot captures experience.

The operator who experiences the bump learns something.

The technician who helps diagnose it learns something.

The shop learns something.

But people eventually forget.

Employees change.

Machines change hands.

Owners retire.

A written machine history allows the lesson to remain.

That is how experience becomes knowledge.

And knowledge becomes part of the system.

Central Lesson

When a test fails, don’t give technical support a guess. Give them the event, the evidence, the tests, the baseline comparison, and the pattern.

The Machine Event Snapshot turns:

“Something happened and the machine doesn’t seem right.”

into:

“Here’s what happened. Here’s what passed. Here’s what changed. Here’s what repeated. And here’s the evidence.”

That is a much better place to begin.

Next — 21: Return to Service — and Prevent the Next Bump

Eventually the problem is resolved.

The machine passes the appropriate checks.

Confidence has been restored.

Now there is one final job.

Don’t simply close the Snapshot and forget the event.

Ask:

What did this bump teach us?

The final section will close the loop between After the Bump and Before the Bump by turning the event into a practical prevention improvement.

 

Leave a Reply