When the Screen Went Dark: Recovering a Production Line’s HMI

One of our production lines runs on a Siemens SIMATIC touchscreen panel, the interface our operators use to control conveyor speed, temperature, and recipes. The screen damage was brought to my attention this Tuesday at noon, the display was completely dead, no touch input either. The initial goal was simple: get a display working again by whatever means possible.

Diagnosing before reaching for tools. The first idea was to get video out through one of the panel’s other ports, RS422/485, Ethernet, or USB. None of those were built for that, and neither this panel nor the spare we had on hand supported hooking up an external display at all. Looking at the actual unit made that clear before any time was lost chasing it. Recognizing that early meant pivoting toward a network-based recovery instead, a different route to the same goal rather than continuing down a path that couldn’t have worked. It also helped that the damage itself was fully visible and understood from the start, a dead screen is a known, bounded problem, so there wasn’t much risk of making the situation worse while working through it. Every step from there was either progress or a safe dead end.

Finding the panel blind. With no screen to check network settings, the only way forward was through indirect signals: link lights to confirm the physical connection was live, ping sweeps to hunt for the panel on the network, and eventually a packet capture in Wireshark to catch it announcing itself at boot. That’s how we found it was sitting on a subnet nobody had documented or expected.

Securing the data before anything else. Before attempting any further recovery, a full backup came off the panel via Siemens ProSave, OS, runtime, and recipe data intact. That backup ended up being the thing that made every later step lower-risk, there was always a known-good fallback if a later step failed.

Tracing down the real source file. The panel had been deployed without its editable project retained on the device itself, a common practice since it saves space, but it meant the panel alone couldn’t produce an editable project to work from. The actual source turned out to live inside an integrated STEP 7/WinCC flexible engineering project on a shared file server, filed in a way that wasn’t obviously connected to this specific machine. Finding it meant knowing to look past the panel entirely and into how the original integrator structured their project files.

Converting across hardware generations. A spare panel, a different model in the same product family, was on hand and made an attractive candidate for an immediate replacement, though getting it to actually function wasn’t as simple as swapping hardware. It meant working through Siemens’ device-type conversion process, resolving a couple of compatibility warnings tied to legacy hardware controls that don’t exist on the spare, and checking every screen against the running machine before calling it done. That work, including getting a Windows 7 VM spun up to edit the old software, had the spare panel up and running on the line the next morning.

Knowing where to stop. The one thing we didn’t force in the meantime was the panel’s recorded recipe data, real production history, not just configuration. Extracting it safely required matching hardware that wasn’t available yet. Rather than risk that data on an incompatible restore, the call was made to hold it safely in the backup and recover it properly once the right replacement panel arrived, with operators re-entering known values on the interim panel in the meantime.

Closing the loop with the right hardware. A matching replacement panel arrived the following morning and was restored to full functionality within the hour using the ProSave backup, no conversion needed since it was the same hardware. That panel is now running the line going forward, less than 45 hours after the original failure was first reported. A second matching unit expected next week becomes the shelf spare. The original panel, screen shattered but board potentially still sound, gets kept as a board-level parts source if either of the other two develops an internal fault down the road. The interim panel goes back to general spare stock for other equipment, not tied to this line. Knowing the workaround wasn’t the destination, and having a clear path back to the original hardware, kept the interim fix from turning into a permanent patch.

A word on the tools used to get here. Claude was used throughout as a working sounding board and technical reference, helping structure the diagnostic sequence, work through Siemens-specific tooling, and reason through networking steps like the Wireshark capture that ultimately located the panel. It didn’t replace hands-on judgment or decisions about risk, but it was a genuinely useful component in getting to resolution faster.

The lesson that outlasted the trial. The single biggest factor in getting this resolved wasn’t any one diagnostic trick, it was that a backup existed at all, and that a source project, even one filed in a spot nobody remembered, hadn’t been lost. Neither of those things happened by luck. Since then, we’ve been treating HMI and PLC source files the same way we’d treat any other critical asset: backed up deliberately, stored somewhere findable, and not left to live only on a single piece of aging hardware on a production floor. That’s now a standing practice across the team, not just something one person happened to get right on a hard couple of days.

The other lesson was more about judgment than process: knowing when to pivot to a different approach that still moves toward the same goal, rather than pushing on a path that’s already dead, and knowing when to step back and bring in someone with deeper expertise rather than solving everything solo. Both mattered as much as any individual fix.