Why your system isn’t proven until it’s running in the field
There’s a point in every project where the CAD is clean, the checklist is green, and you think the system is ready to run. Then you show up to commission it… and reality punches you square in the spec sheet.
This trip to North Carolina was a reminder of that.
We’ve been working on a fully automated rotor coating line — heavy-duty chain-on-edge conveyor, gas-fired ovens, explosion-proof Fanuc robot, Cyclomix 2K system, the works. On paper? Solid. In the shop? Solid. But once we started spraying in the field, the material and sensors had other plans.
Thick Like Syrup, Sprayed Like Garbage
The first test parts were, generously, inconsistent. The coating material was far too viscous — about six minutes in a #2 Zahn cup. That’s syrup. Not paint. We knew it was thick going in, but it wasn’t until we tried to atomize it that the real issues showed up: uneven film builds, overspray, and wasted time.
We thinned it down to about two minutes. Huge improvement — more control, better coverage — but still not where we need to be. Target is around one minute or lower for this application. That’ll be the next step during the follow-up trip.
Thermocouples, Lead Times, and Improvised Engineering
Then came the ovens. Turns out three out of four thermocouples were bad. Oven interlocks wouldn’t function properly, and the OEM quoted a ten-week lead time for replacements. That wasn’t going to cut it.
So… I made one.
Engineered for urgency, not elegance.
It wasn’t elegant — just twisted thermocouple wire, jammed through the oven door so we could get a temperature reading and keep testing. Not exactly textbook, but it worked. We also ordered some temporary replacements off eBay just to get back to a testable, semi-operational state.
Bug Hunts, Timeouts, and Lockups
The viscosity issues didn’t just mess with spraying — they triggered a cascade of software weirdness.
During testing, we occasionally ran a flush cycle. The robot would move to its flush position and trigger the Cyclomix 2K system to start flushing. But because of how thick the paint was, the mix system never actually finished the flush.
To avoid hanging the system, I coded a timeout function: if the flush took too long, the robot would just go home and fail gracefully.
What I didn’t expect was that this long idle timeout would trigger a bug in the robot controller — an internal spray-on calculation would overflow, and the entire Fanuc controller would lock up hard, requiring a full power cycle.
It took a while to figure out what the heck was going on, but thankfully Fanuc was helpful and we came up with a workable resolution. Still — just another case of the real world being way messier than the codebase.
You Can’t Solve This from Behind a Desk
This is why field time matters. You can spec all the right gear. Model flow rates. Quote throughput and efficiency. But you can’t simulate the feel of a system running under real conditions — the little things that break, clog, misread, or flat-out don’t do what you expected.
Until you’ve:
- Watched the robot coat a real part
- Burned two days chasing viscosity issues
- Twisted together a makeshift thermocouple
- Spent hours power-cycling a robot to debug a flush logic bug
…it’s all theory.
What’s Next
I’ve asked the team not to run the line until the eBay thermocouples are installed and interlocks are restored. I’ll be back on-site the 28th to continue testing — thinning further, refining the spray window, and getting the system into production shape.
I’m confident we’ll be spraying good parts that week.
Bottom Line
If you’re building automation systems and not standing next to them during startup, you’re missing the part where theory becomes reality. You don’t know how something really works until you’ve seen it fail — and fixed it.
It’s not real until it runs.
It’s not done until it’s proven.
And sometimes, it runs because you jammed a thermocouple through an oven door… and debugged a robot crash you caused trying to keep the line from hanging.