Case in point: I had a customer that was experiencing splitting on a stamping.

Certain coils would run fine. Others would have 90%+ failure.

I get their process data and run a formability simulation.

The result? A good stamping. No risk of failure.

I then ask for tool architecture data. They had a holding pad that did not really serve a purpose. But, I model it up anyway and re-run the simulation.

Good results.

I then ask for force and travel information off the actual tool. I wanted it down to individual spring locations.

I model that up and re-run.

Still, no failures.

I have the customer take a sample from a failing coil and have an independent laboratory give me engineering properties for the material.

I model that up. And after this iteration, the formability is just fine.

On a conference call with the customer, we brainstorm the root cause.

We come up with nothing.

At the end of the call, the press operator comes into the room.

“Hey Tim. This material feels like it is corrugated. And it is really gritty, just like sandpaper. The other coils we run fine are not like this. Thought I would mention it.”

Thought you would mention it? We just found the root cause.

Now, the formability analysis software on the market takes material texture, tool texture, lubrication, and heat and throws it all into one variable: coefficient of friction.

I tweak that variable from a standard 0.20 to 0.15.

Lo and behold, my model now fails EXACTLY like the production stamping.

Exactly.

The customer is ecstatic.

As engineers, we spend our lives trying to make something work.

In this case, I had to purposely make something break.

I write an article titled Make it Break: How to Make a Successful Simulation Fail for a confidential newsletter published by the formability software company.

The customer loved the article. I thought it was one of my best.

The point to the story was simple: the trials of tribulations of making the formability fail instead of making the formability pass.

It was that simple.

Now, I write for the average die guy. I am an average die guy. I like to keep it simple. My goal is to write in a clear, concise, and precise manner. Free from needlessly complex jargon and the theoretical analysis.

So, what happens next?

The software company has alot of PhDs. Alot.

One of them wants to run a statistical variation analysis to judge the sensitivity of the process to different variables.

Ok. We had already solved the problem. We identified the root cause, and developed corrective and preventative action plans.

The process is sensitive only to the surface texture of the material. Nothing else mattered.

But, the statistical analysis was done.

The results were wrong because the assumptions were wrong.

I go in and tweak the numbers to get the result to agree with what I already know.

This statistical thing was added to my article under protest.

The publisher initially refuses to publish the work because it was “missing” the equations, charts, and graphs.

I explain the intent of the article. It now gets published under their protest.

Then comes the phone calls and emails.

All these PhDs start asking for the model. The equations. The inputs.

They wanted to fix the problem and get the stamping to pass instead of failing.

The only purpose of the article – the message – was this was the one in a million jobs where success meant failure.

It was the complete opposite of how us engineers are supposed to think.

That’s it.

That was July 2009.

And I am still getting emails from those that have missed the point.