Deploying AdvancedHMI View-Only Displays Centrally

A shared network copy removes the need to reinstall the view-only application on 7–10 laptops after every screen change. Place the complete built application in a controlled file-server directory and give each viewer a shortcut to the executable; use the browser snapshot server only when browser access matters more than live desktop behavior. Validate permissions, dependencies, display scaling, and update handling before making the shared copy the production entry point.

The number that matters is the number of independently maintained copies. A 43-inch plant display and a laptop can show the same values, but ten local installations create ten opportunities for version drift, missing files, and inconsistent scaling.

Symptoms and deciding constraints

The primary symptom is administrative: every display edit triggers another round of copying or installation. The secondary symptom is presentation-related: the same build can appear correct on the development PC but compressed or squashed on another PC. Treat these as separate faults. Central deployment addresses version distribution; client display configuration addresses geometry.

Central-distribution mechanism

A local installation couples the application version to each laptop. Replacing the build on one machine changes only that machine. A shared-file deployment reverses that relationship: every shortcut resolves to one executable set on the plant file server, so the next application launch loads the centrally stored revision.

This design centralizes files, not execution. Each laptop still runs its own process and establishes whatever data connections the application normally uses. Ten viewers can therefore create more client sessions and polling traffic than one centrally running instance. Because the screens are display-only, remove or disable control paths in the application itself; a read-only operating intention is not a security boundary if writable controls or credentials remain present.

SimpleWebServer changes the delivery mechanism. It exposes a snapshot of one form and refreshes that snapshot automatically every several seconds. That suits passive status viewing, but it is not equivalent to a continuously rendered desktop client. The browser sees published images at the configured cadence, so short-lived changes between refreshes may not be visible.

ClickOnce retains a per-user application while automating update discovery. The deployment is published through a web server, users follow an installation link, and the application checks the deployment location again when it starts. This reduces manual redistribution but introduces publishing configuration and deployment-state behavior that must be tested.

Deployment-method comparison

For the stated 7–10 viewers, the shared executable is the shortest path when all clients already authenticate to the same plant file server. Choose the web snapshot only after accepting its refresh interval and limited interaction model. Choose remote access only when the site can define whether viewers share one session or receive separate sessions.

Shared-executable deployment procedure

1. Confirm the view-only boundary. Review every displayed form and navigation path. Remove commands that write values, start equipment, acknowledge conditions, change setpoints, or expose configuration. Apply read-only data permissions where the data source supports them.
2. Build a release set. Collect the executable and every file it requires at runtime. A successful launch from the development output directory does not prove that a copied executable alone contains all required libraries, configuration, images, or other resources.
3. Create a controlled share. Place the release set in a plant file-server directory reachable by the intended users. Grant viewers read and execute access; reserve modification rights for the maintainer or deployment account.
4. Test from a representative laptop. Sign in as a normal viewer, browse to the shared directory, and launch the executable. Confirm startup, data updates, navigation, and access to all resources without relying on development-machine paths.
5. Create desktop shortcuts. Point every client shortcut to the same network executable path. Check the shortcut target directly on each laptop rather than relying on its displayed name.
6. Control the update window. Have viewers close the application before replacing the shared release set. Open processes can hold files or leave a user on the previous in-memory revision until restart.
7. Deploy the complete set. Update the executable and associated runtime files together. Avoid mixing files from different builds, because partial replacement can create startup or behavior differences that resemble an application defect.
8. Restart and verify. Launch through the same shortcut a normal user will use, then confirm the build identity and live values from more than one client.

Keep the previously accepted release available through the site’s normal backup or version-retention process. If the new build fails, restoring a known complete set is safer than replacing individual files until the application happens to start.

Browser-snapshot procedure

Use SimpleWebServer when users specifically need a browser and a snapshot refreshed every several seconds meets the monitoring requirement. Firewall behavior is a recurring obstacle because the browser must reach the host service across the plant network.

1. Select the published form. Designate the one form whose snapshot will be exposed. Put all essential metrics on that form because the component’s stated scope is one form.
2. Place the host deliberately. Run the source application and web component on a machine intended to remain available while managers view the page. Browser availability now depends on that host, its application process, and its network path.
3. Configure network access. Read the listening address and port from the component or host configuration. Request only the firewall path required between the viewer network and that endpoint.
4. Test locally, then remotely. Open the page on the host first. Next, test from a normal viewer laptop; a local success followed by a remote failure points toward addressing, routing, firewall, or name-resolution work rather than screen logic.
5. Measure useful refresh behavior. Change a displayed source value and observe when the browser snapshot changes. Verify that the several-second cadence is acceptable for the metrics and that no operational decision depends on events shorter than the observed interval.

The published page remains a viewing surface, not proof of data freshness. Add a visible changing value or application timestamp if the project already has one available; otherwise compare the browser with the running source form during acceptance testing.

Functional and visual verification

Verification must prove version consistency, data freshness, and screen geometry independently. A correct version can still display stale data, and a live connection can still render a distorted layout.

1. Open the application from two viewer laptops and record the executable path shown by the shortcut or running process.
2. Confirm both paths resolve to the same shared release set and that both clients report the intended build identity through file properties or an application version display.
3. Compare several changing plant values with the established reference display. Include a value that changes often enough to reveal a frozen connection.
4. Close one client, deploy a controlled screen change, and restart that client. Confirm the change appears without copying files to the laptop.
5. Repeat the restart on a second client to prove that update behavior follows the shared path rather than a machine-specific cache or old shortcut.
6. Compare the development PC and an affected laptop for operating-system resolution, display scale, text size, and usable desktop area. Then inspect the application’s fixed dimensions, anchoring, docking, and automatic-scaling choices.
7. Test the smallest and largest client display configurations used in service. Check clipped labels, overlapping controls, stretched graphics, unreadable text, and hidden navigation elements.

A squashed screen is usually a coordinate-system problem: the form was laid out for one logical-pixel or font environment and another client maps those dimensions differently. Match the client display settings where operational policy permits, or revise the screen layout so controls resize and anchor predictably. Changing central deployment will not by itself correct client-side scaling.

Recurring deployment pitfalls

Copying only the .exe. Development machines often already contain files or runtimes that mask an incomplete deployment. Test the full release set under a normal user account on a machine that was not used to build it.

Updating while clients are running. A shared location gives one update point, but a running process may retain the old code in memory or lock files. Use a defined close-update-restart sequence and verify that no viewer remains on the previous revision.

Confusing view-only screens with read-only security. Hiding buttons reduces accidental operation but does not remove write capability from drivers, credentials, or unseen navigation paths. Restrict permissions at the data-access layer and test with the actual viewer account.

Treating snapshots as real-time displays. A several-second browser refresh can omit a short transient. Use it for metrics whose required observation interval is slower than the measured refresh behavior.

Using one remote session without an access model. Multiple users can contend for the same pointer, keyboard, session, or login. Define concurrency, authentication, audit expectations, and session ownership before using remote desktop software for plant information.

Diagnosing geometry through resolution alone. Two PCs can use similar pixel dimensions but different display or font scaling. Record all display settings and inspect the application’s layout behavior before rebuilding screens.

FAQ