At the final demonstration of the course, each of us had to run the small material-sorting machine we had built and show it to the instructor.

A few days before the demonstration, the instructor placed a sheet of paper on our workbench. It was neither a drawing nor an instruction manual, but a handwritten list of “acceptance criteria”: the conveyor speed had to remain stable; sorting errors could not occur frequently; materials could not get jammed; the machine had to stop immediately in an emergency; and it had to withstand continuous operation…

Each requirement looked ordinary on its own, but together they amounted to one simple message—

Getting it to run is only the beginning. What matters is whether it can keep running reliably.

My setup was not complicated: a conveyor belt transported the items, a sensor identified their colors, and a pneumatic cylinder pushed them into different channels. It seemed so simple that it created an illusion—as long as the program was written correctly, the machine would obediently do its job.

The first time I started it, I realized how much I had underestimated the problem.

The moment the pusher extended, some items were knocked out of alignment. They clipped the edge, bounced slightly, and failed to enter the chute. I stopped the machine, straightened the item, and tried again. This time it worked. But the next batch failed—the pusher returned half a beat too slowly, the second item had already arrived, the conveyor was still moving, and the two items crowded together. An alarm sounded, and the machine stopped.

After clearing the jam, resetting the system, and restarting it, the machine carried on as though nothing had happened.

The most frustrating part was this:

With exactly the same settings, sometimes it failed and sometimes it did not.

I could neither pin down the error nor explain why it happened.

So I began adjusting parameters by intuition: slowing the movements, extending the waiting time, and adding more fail-safe logic. These changes did make the system look more stable, but the cost was obvious—the speed could not be increased. If I tried to make it faster, it became chaotic; if I tried to make it more stable, it became slow.

After two days of repeated testing and shutdowns, I began to doubt myself:

Was I really solving the problem, or was I simply relying on luck?

Then, after watching me stop and reset the machine yet again, the instructor quietly asked:

“Which operating condition are you tuning for right now?”

I froze.

I suddenly realized that all along I had only been tuning the machine for “this moment”:

this particular batch of items, this particular spacing, this particular air pressure, and a sensor that happened to be triggering normally at that instant.

Change the batch, alter the rhythm, or increase the speed even slightly, and the barely workable state I had just achieved might disappear immediately.

In other words—

I had not solved the problem. I had merely confined it within a very narrow range of conditions.

The instructor said, “Stop gambling on the physical machine. Run a simulation first.”

I had used simulation before, but mostly to complete assignments: build a model, obtain a result, take a screenshot, and submit it.

This time, for the first time, I treated simulation as a real tool.

It was not about producing an attractive demonstration. It was about placing all the scenarios that I did not dare—or could not afford—to test on the physical machine inside a screen, and letting them reveal what was really happening.

The first thing I did was break the entire process down completely.

An item arrives, is identified, is pushed, the pusher returns, and the next item passes through… I wrote down, step by step, when each action began, when it ended, and what condition the next action depended on.

The vague instructions I had relied on before—“wait a moment” or “add a little delay”—became concrete questions:

What exactly was the system waiting for? Was it waiting for an action to finish, or merely letting time pass?

Then I isolated the factors most likely to cause trouble: item spacing, conveyor speed, pusher speed, and recognition delay.

In the real system, these factors always changed together, making it difficult to identify which one was causing the problem.

In simulation, however, I could change one variable at a time and run the process repeatedly.

I began deliberately making things difficult for the system.

I reduced the spacing between items, increased the speed, and slowed the pusher.

Soon, the intermittent fault that had been so elusive in the real setup was reproduced consistently.

When the items arrived too closely together, the previous item had not yet been processed before the next one appeared. The system then faced a dilemma: either pause and sacrifice efficiency, or continue anyway and sharply increase the probability of error.

At last, the problem became clear—

It did not lie in any single parameter. It lay in the process itself.

The system lacked a mechanism for dealing with moments of congestion.

From that point on, my entire way of thinking changed.

Before, I patched each failure wherever it appeared: slow it down, wait a little longer, add another condition.

Now, I began redesigning the process:

Make the system confirm its state at critical points before moving on, instead of guessing based on elapsed time;

Give it a clear strategy for excessive item density—slow down, pause, or reorganize the rhythm.

The goal was no longer to avoid disorder, but to manage it.

This may not sound sophisticated, but it was extremely effective.

In simulation, I could keep pushing the system toward its limits: faster, denser, slower. Every failure could be repeated, and every modification could be compared.

The experience was completely different from working with the physical machine.

The real setup felt like a gamble—you saw only the outcome: right or wrong.

You could not see what happened in between. You could only infer the cause from whether a failure occurred.

In simulation, however, the black box was opened.

You could see how each step unfolded, how “congestion” gradually developed into a “failure,” and how time moved through the system.

At last, you could say:

“This is why it failed.”

Instead of merely saying—

“It failed again.”

When I brought the revised plan back to the physical machine, I was no longer nervous.

I was no longer hoping that “nothing would go wrong this time.” Instead, I knew when the machine would slow down, when it would stop, and when it needed to wait a little longer.

The real machine still had fluctuations, of course, but it no longer exposed problems randomly.

It began handling deviations according to clear rules.

I have often thought back on this experience.

What mattered most was not the successful final demonstration, but the shift in thinking:

from the original question—

“How can I stop it from failing this time?”

to the later question—

“How can I make sure it knows what to do under all kinds of conditions?”

The former depends on luck.

The latter is design.

Simulation helped me make precisely that transition.

It may look like a waste of time—

testing again and again in a virtual world, and failing over and over.

Yet it is precisely these “permitted failures”

that prevent the real world from taking unnecessary detours.

The time that seems to be wasted in the simulation world

will ultimately be repaid many times over in the real world.

About the Author

Li Xuran

Master’s Student, School of Intelligence Science and Engineering, Southeast University