The fault that only shows up once a shift

Wilmer Ramirez — Mon, 26 Oct 2026 03:44:47 +0000

Every plant has one. A fault that shows up once a shift, sometimes once a week, and clears before anyone gets to the screen. The operator swears the machine stopped. Maintenance checks everything and finds nothing. Production wants an answer, and you've got nothing but a story about a light that blinked.

I'll be straight about this: tools that record signals already exist, and some are damn good. I'm an automation engineer, I use ibaPDA at work. It's pro gear, and it's paid. I'm not here to pretend I invented this.

TRACE came from a different problem. Sometimes you need to chase one specific fault, right now, out on the floor, and you don't have time for a heavy setup. Or you want to test something in the lab before you drag software out to the field. A full pro setup is overkill for that, and getting one approved and configured can take longer than the problem gives you.

So TRACE is a Windows app that records Allen-Bradley PLC signals. You set it up, let it record, and when the fault shows up, you play it back and see what the tags were doing. No guessing. You watch what actually happened.

No PLC on your desk? There's a simulation mode. You can mess around with recording and playback, or test your approach in the lab, before you ever touch the real line.

It's free. No account. It runs on your PC, and your plant data stays yours.

You can grab it at siganor.com. Try the simulation mode first. Next time that once-a-shift fault shows up, you won't just have a story. You'll have the recording.

I also built Siganor Search, same idea but for finding files on your PC. I'll write about that one next.

The ESP32 in Industrial Automation: Let’s Get Real

Wilmer Ramirez — Mon, 14 Sep 2026 14:47:08 +0000

We’ve been arguing for years about whether the ESP32 belongs on the factory floor just because it has tons of processing power, built in Wi-Fi, Bluetooth, and native peripherals. But honestly, that’s the wrong debate. The real question isn’t whether the chip can crunch the data. It's about what you need to build around it so it doesn't smoke the second it faces a real world manufacturing environment.

Let’s be real: a five dollar dev board sitting on an engineer's desk is not a PLC, and treating it like one in production is a recipe for disaster. That said, looking at today’s ecosystem with solid support for Ethernet, Modbus, CAN/TWAI, or RS-485 via external transceivers the platform has massive potential if you actually design it right.

The headaches start when you leave the lab. Throwing an ESP32 into an electrical cabinet right next to variable frequency drives (VFDs), massive contactors, and high voltage motors is a whole different ballgame. That’s where real engineering kicks in. If you want the system to survive, you need to design a proper board around it. We are talking industrial grade power supplies, absolute galvanic isolation, transient and reverse polarity protection, proper signal conditioning for 24 VDC or 4–20 mA loops, solid EMC shielding, and a decent DIN rail enclosure.
If your peripheral hardware is garbage, it doesn't matter how fast the processor is.

The beauty of this platform isn't about replacing Rockwell, Siemens, or Beckhoff. The ESP32 shouldn't be competing with the main PLC; it should be doing the dirty work the PLC wasn't meant to handle or can't do easily.
Think about that nightmare intermittent fault a random sensor dropping out once or twice a shift, driving the maintenance crew crazy. Risking a production stoppage to modify the main PLC logic just to catch a millisecond glitch is usually a hard sell. Instead, you drop a small ESP32 box in parallel, log the signal transitions locally with a timestamp to an SD card or push them over Wi-Fi to a local server, and walk away. You get a temporary, isolated diagnostic tool without touching a single line of critical process code. It’s an absolute lifesaver for rapid telemetry, custom data logging, or protocol bridging.

However, there is a hard red line here: functional safety. Just because an ESP32 can execute logic doesn't mean it should ever touch an E stop circuit, a light curtain, or a critical interlock. SIL and PL safety ratings aren’t bureaucratic nonsense. They require strict hardware redundancy, predictable fail safe modes, and architectures designed specifically not to kill anyone if the software locks up.

In industrial engineering, the ultimate question is always: “What happens when this thing hangs, loses power, or blows a transceiver?” If the answer involves severe equipment damage or human injury, the ESP32 has absolutely no business being there.

At the end of the day, the ESP32 is a fantastic tool for solving real problems fast and on a budget. It’s perfect for prototyping, building diagnostic gear that used to cost thousands, deploying distributed sensor networks, or pulling data from legacy machines into the company's IoT backend. It’s not about flooding the plant with cheap electronics; it's about having a killer wildcard in your back pocket when the factory's main automation platform leaves you blind.

DEV Community: Wilmer Ramirez

The fault that only shows up once a shift

The ESP32 in Industrial Automation: Let’s Get Real