Documenting Your Industrial Touchscreen Before It's Too Late

Ask around most FNQ plant rooms and you'll get the same answer about backups: "Yeah, the bloke who installed it has the file." That's not a backup plan. That's a single point of failure sitting on a laptop somewhere, and in most cases the bloke has moved on, retired, or closed up shop.

A proper backup of a machine touchscreen (HMI) isn't just the project file. It's a set of documents that let any competent tech pick up the job if the panel dies, the installer vanishes, or someone new inherits the system. Here's what actually needs to exist.

What a Real HMI Backup Includes

The project file is the centrepiece, but on its own it's not enough. A complete set covers:

• The project file itself (.emtp for Weintek, .pkg for Kinco, .twe for Touchwin, etc.) stored somewhere other than the installer's laptop.
• Editor version info. Which version of EasyBuilder Pro, DTools, or EditTool built the file. Open it in the wrong version and you're locked out.
• Comms configuration. Protocol (Modbus RTU, Modbus TCP, something proprietary), baud rate, station address, controller make and model, cable pinout.
• Register / tag map. A list of every register the HMI reads from or writes to the controller, with plain-language notes on what each one does. This is the single most valuable document on site.
• Screen hierarchy. A sitemap showing how an operator navigates the panel, and what each screen is for.
• Alarm list. Every alarm, which register triggers it, what threshold, what action the operator is supposed to take.
• Recipes and setpoints. Any stored product recipes or tuning parameters, exported to a file that isn't locked inside the panel.
• Controller program alongside, when the HMI and controller are a matched pair. An HMI backup with no corresponding PLC backup is half a backup.
• Change log. Dated notes on what changed, when, and why. Doesn't need to be fancy. A text file works.
• System description. One page explaining what the panel controls, who owns it, who looks after it, and what the consequences are if it goes down.

Why "Project File Only" Isn't Enough

A project file on its own is a binary blob. The next person to look at it (and there will be a next person) faces:

• Opening it with the wrong editor version and getting errors or silent conversions.
• Seeing register numbers with no idea what they do or which ones are live.
• No way to know if what's on the panel right now matches what's in the file.
• No record of what's been changed over the last five years.
• No way to recover from a panel failure without also rebuilding the register map, alarm logic, and comms settings from scratch.

We see this every month. A plant manager hands us a USB stick, says "this is the backup," and the file turns out to be three versions behind what's actually on the running panel. Or the file opens but the register numbers mean nothing because nobody documented the tag list.

Signs Your Site Is at Risk

Quick test. Can you answer yes to all of these?

• [ ] You have the HMI project file stored somewhere other than the installer's laptop.
• [ ] You know which version of the editor software was used to build it.
• [ ] There's a register map explaining what each tag does.
• [ ] The comms settings between HMI and controller are written down.
• [ ] The alarm list and thresholds are documented.
• [ ] Someone currently on site knows what the panel does.
• [ ] The backup is dated within the last 12 months.
• [ ] The corresponding controller program is also backed up.

If you're hitting "no" on more than a couple of those, your site is one panel failure away from days of downtime.

Audit Your Own Site in an Afternoon

Walk the plant with a notepad and run through this for every touchscreen:

1. Identify the panel. Make, model, software version if you can read it off the panel info screen.
2. Find the project file. Ask who's got it. If the answer is "the installer," treat that as no backup.
3. Check the date. Compare against the last time you know the panel was modified. If it's older, the file is stale.
4. Find the register map. If it doesn't exist, write down every tag reference you can find on the panel and what it appears to do.
5. Document the comms. Controller brand, model, protocol, cable type. Ten minutes with a phone camera covers most of it.
6. Note the alarm list. Screenshot the alarm screens during normal running.
7. Write a one-line description. What does this panel control? What happens if it dies?

An afternoon of this at most FNQ sites turns up multiple panels with no real backup. That's the point. You can't fix a problem you can't see.

Where We Come In

If you run through the audit and the gaps are bigger than you can close yourself, that's what we do. We come out, pull a proper backup off every panel, build the register map and comms documentation, and hand back a full set. Weintek, Kinco, Touchwin, Delta HMI and more.

Get in touch for an assessment. It's a conversation worth having before the first panel dies, not after.