Configuring TD850 Panel Shutdown: Power-Cut vs Button

An operator drops the main disconnect at end of shift, the TD850 screen goes dark after a beat, and the next morning Windows comes up without a repair prompt. That beat is not the panel dying — it is the panel running a full operating-system shutdown on stored energy. Understanding which of the two shutdown paths is running, and proving it completes, is the whole job.

Which shutdown path does the panel actually take?

The TD850-AEB-7EP runs Windows Embedded Standard 7 with the LogicLab runtime and PageLab pages on top. Both shutdown methods end in the same place — a clean OS stop — but they get there from different triggers.

Action	Trigger path	What the screen shows	Result
Hidden front button, short press	ACPI power-button event to Windows	Normal Windows shutdown sequence, supply still present	Clean OS stop, then board powers off
Supply removal	Undervoltage detection on the DC rail, panel initiates assisted shutdown on stored energy	Display goes dark quickly; shutdown completes unseen	Clean OS stop inside the hold-up window

The distinction that matters operationally is not "soft versus hard". It is "assisted versus override". Removing supply is assisted. Holding the button is the only genuinely destructive option on the panel.

Check before moving on: open Power Options and confirm the power-button action is set to Shut down, not Sleep or Hibernate. A panel configured for Sleep looks identical to the operator — screen off, machine quiet — but the OS is parked in S3 with the file system open, and the next power interruption is then a genuine hard stop.

Why doesn't repeated power-cut shutdown wear the reserve out?

The energy reserve is not a battery. It is a bank of supercapacitors, and that single fact removes the concern about cycling. A lithium or NiMH pack degrades on cycle count and depth of discharge, so a machine cycled several times a shift would measurably shorten its life. Supercapacitors survive thousands of charge/discharge cycles, with no memory effect and no charge-termination chemistry to abuse.

The margin is generous as well. Every shutdown uses a fraction of the stored charge and stops well before the bank is deeply drained — the mildest possible duty for this technology.

So there is no contraindication to shutting the panel down by removing supply, continuously, as the normal operating procedure. Neither the reserve nor the operating system is damaged by it.

Check: time the interval from breaking the supply to the display going fully dark. Repeat ten times and take the worst case. Anything at or under 6 seconds means the assisted path is working as designed.

Is the OS finishing inside the 6-second window?

The 6 seconds is a budget the panel guarantees, not a promise about your image. Windows shutdown time grows with what you install on it — antivirus, a service with a long stop timeout, a pending update that stages on shutdown, a network share that will not disconnect.

The Windows event log is the truth source here. After a power-cut shutdown, reboot and read the System log:

Event ID	Source	Meaning
1074	User32	Shutdown initiated by a process or the power button — the clean path
6006	EventLog	Event log service stopped normally — the OS reached the end of shutdown
6008	EventLog	Previous shutdown was unexpected — the OS did not finish
41	Kernel-Power	System rebooted without a clean shutdown — hard stop

A healthy power-cut shutdown produces 6006 and no 41 or 6008. Also query the dirty bit from an administrator command prompt:

fsutil dirty query C:

A volume reported as dirty means the last stop was not clean and chkdsk is queued for the next boot. Trim shutdown time — disable unused services, stop antivirus real-time scanning on the runtime data paths, disable automatic updates on a machine image — until 6006 appears every cycle.

How do you keep the runtime's data safe across the cut?

Clean OS shutdown protects the file system. It does not automatically protect an application file that was mid-write when the rail dropped. Recipe files, logged trends, and PageLab-written data are the exposure.

1. Keep retentive process data in the LogicLab retain area rather than in application files written on every cycle. Retentive memory is handled by the runtime's own persistence mechanism, not by an open file handle.
2. Where files are unavoidable, write with a temp-file-then-rename pattern so a truncated write never destroys the last good copy.
3. Close log and recipe files between writes instead of holding a handle open for the whole shift.
4. Consider enabling a write filter on the system volume so the OS partition is never written at all in normal operation, with a separate unprotected volume or overlay exclusion for runtime data. Confirm which filter components are present in your image before designing around one.
5. If the application needs to know a shutdown is in progress, have the runtime react to the OS shutdown notification and flush before the process is terminated — not after.

Check: cut power during an active logging write, reboot, and verify the log file opens without corruption and the retentive variables hold their last values.

Can you remote the hidden front button?

The tag is right; the binding is wrong on this one. The requirement is "shut the panel down from outside the enclosure", and the front button is only one way to satisfy it. Do not tap into the button harness — that circuit is an ACPI input on the board, not an isolated dry-contact interface, and paralleling field wiring onto it invites nuisance shutdowns from coupled noise.

Two supported approaches, both better than remoting the button:

1. Break the supply upstream. A contactor or a keyed disconnect feeding the panel's DC rail produces exactly the assisted shutdown described above. Given the supercapacitor reserve, this is the simplest and most reliable remote-shutdown method available, and it is the one already proven on the panel.
2. Command shutdown from the application. Read a hardwired digital input or a fieldbus bit in the LogicLab program and, on that condition, have the runtime invoke the operating-system shutdown. Windows then performs a normal stop while the supply stays present — identical in effect to the front button, with no mechanical access required.

Approach 2 is preferable when the panel must stay powered for a peripheral, or when you want the shutdown reason recorded in the event log with a specific initiator. Approach 1 is preferable everywhere else: fewer moving parts, no software dependency, and it also covers the unplanned case where somebody drops the disconnect anyway.

Make the break clean. A slowly collapsing rail — weak 24 V supply, large downstream capacitance, several loads decaying together — can hover around the panel's undervoltage threshold instead of crossing it decisively. A contactor that opens the feed hard gives the detection circuit an unambiguous edge and starts the 6-second sequence immediately.

Final verification: the power-cut cycle test

Run this on the commissioned panel with the real project loaded, before handover.

1. Clear the Windows System log, or note the current timestamp as a baseline.
2. Start the machine cycle so LogicLab is scanning and PageLab is updating live values.
3. Break the panel supply at the upstream contactor. Start a stopwatch at the break.
4. Record the time to display blank. Confirm it is at or under 6 seconds.
5. Re-apply power and let the panel boot to the runtime.
6. Open Event Viewer, System log. Confirm 6006 for the previous stop, and confirm no Kernel-Power 41 and no EventLog 6008.
7. Run fsutil dirty query C: and confirm the volume is not dirty.
8. Open the runtime data: verify retentive variables hold pre-shutdown values and the newest log file parses cleanly.
9. Repeat steps 3 through 9 for at least 20 consecutive cycles. Every cycle must produce 6006 and a clean volume.

Twenty clean cycles with no 41, no 6008, and no dirty bit is the proof that power-removal shutdown is safe as the site's standard procedure on this panel.

Frequently Asked Questions