Catch a failing drive before it strands a loaded belt.

Watch the test (3 min, no sound)

When one drive weakens, the others pay for it

Many long or heavy conveyors are pulled by more than one drive. The drives share the load. When one of them weakens or stops, its share moves at once onto the others.

What happens next depends on how much spare capacity your drives have.

• Plenty of margin: the other drives carry the belt. But they run near their limit and wear out several times faster while you wait for the repair.
• Little margin: the other drives overload. Their protection trips them within about two minutes. The belt stops full of material.

Then comes the worst part. A loaded belt needs more force to start than to keep running. With one drive gone, the drives you have left may not be able to restart it. A fault that could have cost you a planned stop now costs hours of digging material off the belt by hand, and a line that produces no tonnes in the meantime.

The failing drive usually warns you first. Its vibration rises. Its motor runs hotter than the others at the same current. The question is whether someone turns those early signs into the right action in time: without overreacting to a normal surge of material, without trusting a dead sensor, and without stopping a healthy line.

Tap the image to see it full size.

What happens when nobody acts

We started a slow bearing failure on one drive. Its lubrication ran out over several hours. Then we let the plant run with nobody acting.

• The bearing wore faster as it worked. Vibration rose. The motor winding ran hotter and hotter.
• Hours later, the drive's own protection tripped it.
• On the plant with little margin, the two healthy drives tripped less than two minutes later.
• The belt stopped loaded, and the two remaining drives could not restart it.

Nothing went wrong with the protection. It did its job. It just did it at the worst moment, with the belt full.

Tap the image to see it full size.

What the AI operator did

This is the run we followed step by step: the bearing failure on the plant with little margin, with a live AI model doing the reasoning. The AI never touches the equipment. It proposes a step; the system checks it against the plant's safety policy; a person approves anything that stops equipment. In the tests, approvals were automated.

1. Named the symptom, not a guess. Drive 3 was running hotter than its two neighbours at the same current, and its temperature was climbing. The cause was not clear yet. The AI said so, called it “a drive degrading against its peers”, and set a watch on drive 3's vibration.
2. Named the cause, and kept producing. When the watch fired, drive 3's vibration was now clearly above the others. The AI named a dry bearing. The system's trend showed the trip was still hours away, so the AI kept full feed. There was no reason to give up tonnes yet.
3. Emptied the belt. As the predicted trip came closer, the AI asked to stop the feeder so the belt would run empty. Approved.
4. Stopped the failing drive by plan. With the belt empty, it asked to stop drive 3. Approved. The drive stopped more than an hour before it would have tripped.
5. Brought the line back on two drives. Drive 3 was cooling and the two healthy drives were sharing the load evenly. The AI restored the feed at a safe, reduced rate that two drives can carry and still restart.

Later that day, a routine stop further down the line halted the belt. The belt carried only a light load, so the two healthy drives started it again. No drive tripped. The belt never stranded.

Tap the image to see it full size.

What it was not fooled by

A good operator acts on a real fault and leaves a healthy line alone. We tested both.

• A normal day and a surge of material. When the feed swings through the day, or a surge loads all drives at once, every drive rises together. That is not one drive failing. In these tests the system raised no alarm and took no action. These control tests ran with the system's rules and a scripted stand-in for the AI; they test the part that decides when the AI is called at all.
• A frozen vibration sensor. We froze drive 3's vibration sensor at a healthy reading just before its bearing began to fail. The sensor looked fine but stopped moving with the load. The system reported the sensor problem first, then caught the bearing from the motor temperature, which kept telling the truth.
• A silent sensor. Same story, but the sensor stopped reporting. The system treated the gap as missing evidence, not as “all clear”, and still caught the failing drive.

The results

All results come from simulation. We score every run on what it cost the plant: tonnes not delivered, a stranded belt, protective trips, drive wear, and stops that were not needed. Each run is compared with doing nothing and with four simple fixed rules, including a plain vibration alarm and today's common practice of cutting the feed after a drive trips.

• The slow bearing failure became a planned stop. In every test run, the failing drive was stopped by plan, before its trip, with the belt empty. The belt never stranded.
• A good warning time. The system predicted the trip about an hour and a half ahead, close to when it really came. A straight-line trend warned later.
• Better than a vibration alarm. A simple vibration alarm also stopped the drive in time, but later and at a higher cost to the plant. The AI operator beat it, and beat the other fixed rules, in every rules-based test run of this story.
• Fast when there is no warning. When a drive tripped suddenly under full load, the feed was cut within seconds, in time to save the other two drives.
• No harm when nothing can be saved. When the lead drive was lost and the plant stopped the whole belt, nothing could prevent the stop. The operator did not try to restart a loaded belt, which would only have added a stall and more heat.
• Every story passed with the live AI. Bearing failure on both plants, sudden trip, gearbox seizure, frozen sensor, silent sensor and loss of the lead drive.

One honest trade-off: after the planned stop, the line ran on two drives at reduced feed. Over the test day it moved a little less material than the run where nobody acted, until that run's belt stranded. We think a restartable belt is worth those tonnes. Your numbers decide that, not ours.

Tap the image to see it full size.

What we learned

The first time we let the AI handle the bearing failure on its own, it held back. The cause was not certain, so it said “unknown” and only watched. That is a safe answer. On a weakening drive, it is also a costly one, because waiting has a price.

It worked once the system around the AI did two things:

• It gave the AI a name for what it could already see: one drive degrading against the others. With that name, the AI could take the steps that are right whatever the cause turns out to be, such as watching closely and planning the stop, without pretending to know more than it did.
• It asked again whenever the evidence changed. The watch the AI set woke it when the vibration moved. Each new question came with fresh readings.

This is why we build Tamoz the way we do. The AI reasons. The system around it decides when to ask, checks every proposal against the plant's policy, and sends nothing to equipment without the right approval. A good model in a loose system gives confident wrong answers or no answers. The same model in a tight system made the right calls here.

A pilot on your conveyor

We are looking for a first partner. A pilot is one problem, read-only, with a result we agree on before we start. Your team stays in control.

1. Pick one problem. For example, a multi-drive conveyor where a drive failure would strand the belt, or drive trips you cannot explain. We agree what would count as success.
2. Get the data. Drive currents, motor temperatures, vibration, belt speed and the belt scale, from your existing systems where possible. Where something is missing, we install sensors, following your site's rules.
3. Build a simulated copy first. Before anything connects to your conveyor, we can replay a sample of your history and build a simulated copy with your drive ratings and restart limits. You see how it behaves first.
4. Watch and investigate, read-only. Tamoz tells your team what it sees, how sure it is, how long a drive may have left, and what step it suggests. Your team decides and acts through your own controls.
5. Review it together. We compare the results with what we agreed, and decide together whether there is a useful next step.

The first question we will ask: if one drive drops out at full feed, can the others carry the belt? The answer decides whether a weak drive is a slow cost or a fast stop, and it shapes everything else.

What we need from you: one person who knows the conveyor, access to its readings or a place to install sensors, and a regular review with your team.

Any later action on your equipment would need a separate agreement. If the pilot does not help, you will know that too, with nothing changed in how your conveyor runs.

Questions plant managers and investors ask

Is this a real conveyor?

No. It is a simulation of a short, flat conveyor, about 60 m long, with three small drives. Its sizes, ratings and failure behaviour are engineering estimates, not data from a customer site. Large bulk-handling conveyors have much bigger drives; the way load shifts between drives, and the restart problem, are the same. We built two versions, one with plenty of drive margin and one with little, because that single fact changes the right response most.

Will the AI stop my equipment on its own?

No. A person approves every step that stops equipment. In these tests, approvals were automated so we could run many tests. A pilot starts read-only: Tamoz recommends, your team acts. Your drive protection and safety systems stay exactly as they are. Tamoz is not a safety function or a real-time controller, and it is not certified as either.

What sensors does this need?

Per drive: current, motor winding temperature and vibration. For the belt: speed and a belt scale. Many conveyors already have some of these, and drive current usually comes from the drive's inverter. Where readings are missing, a pilot can add sensors.

How is this different from condition monitoring or a vibration alarm?

Condition monitoring tells you a drive is unhealthy. An alarm tells you a reading crossed a line. Neither decides when to stop, how to empty the belt first, or how to keep the belt restartable on the drives you have left. In our tests, a plain vibration alarm also stopped the failing drive, but later and at a higher cost. Tamoz keeps your alarms and adds the next step: what is likely happening, how long you have, and what to do.

What if a sensor fails or lies?

A silent sensor is treated as missing evidence, never as “all clear”, so the system becomes less sure instead of guessing. In the tests, a frozen vibration sensor was reported as a sensor fault before anything else, and the bearing was still caught from the motor temperature.

What has not been proven yet?

Quite a lot, and we would rather say so. No real conveyor has run this. The live AI ran a small number of test days per story; more runs on fresh simulated days are next. The trip prediction was tuned on the same simulated days it was judged on. Savings in a real operation have not been measured. A first pilot is how we find out.

Why should an investor care?

A stranded belt in mining, cement or a port terminal can stop an operation for hours. The hard part is not the alarm, it is the decision in the hours before the trip. This experiment shows that decision made correctly, end to end, in a closed loop that grades itself against what would have happened. It is early evidence, in simulation. It is not a savings claim.