Show one front panel on each of several monitors

The property that picks the screen

The property is Front Panel Window » Monitor, written before the VI runs. A Property Node reads and writes properties on an application or a VI, and the Run VI method of an Invoke Node starts the VI. So each screen gets the same short sequence: open a VI reference, write the monitor number, invoke Run VI, and keep the reference open for as long as the panel runs.

The value you write is the monitor's number: 1 for the first screen, up to 8 for the eighth in this setup. The operating system assigns those numbers in its display settings, and the assignment moves when an output is added, removed or re-plugged, so re-read the numbers after any wiring change and update the launcher.

A fixed alternative exists for panels that never move: the window run time position setting in each VI's properties names a monitor at edit time. Use it for a single permanent panel. Use the property route when a launcher decides placement at run time, which is the case when one program serves many screens.

What you need

• One PC with one video output per screen: eight outputs for the eight-monitor example.
• All outputs extended into a single desktop, numbered in the operating system's display settings.
• One display VI template, reused once per screen: indicators only, no state of its own, scroll bars and menus off, front panel sized to the monitor, 1920 × 1080 for a full-HD panel.
• One queue per display, created in the main VI and named after its screen or cell.
• In the launcher, one VI reference, one Property Node and one Run VI Invoke Node per display.

The monitors themselves are ordinary screens. On a plant wall they are shop-floor screens, and the physical questions are the usual ones: text height for the viewing distance, brightness against the room's light, mounting and power. For picking a panel, start in the displays category, and for the pre-buy checklist that applies to any screen mounted in a building, work through the elevator screens guide. Text height follows the signage rule of 30 ft of viewing distance per inch of capital letter height (FHWA): a count read from 10 ft needs capitals about 0.33 in tall, and designing to the safer 20 ft per inch gives about 0.5 in at that same 10 ft.

Launch the panels: step by step

1. Number the screens. Extend every output into one desktop, open the display settings, and write down which physical monitor holds number 1 through number 8.
2. Build the display VI template. Indicators only, no local state, front panel sized to fill the monitor, no scroll bars.
3. Create the queues first, one per screen, named after the cell or the screen number so each template instance can find its own.
4. For each display, open a VI reference in the launcher. On the development machine you can wire the full path; in a built executable the path is relative to the application, and the display VI must be part of the build.
5. Write the monitor number: one Property Node per display on the property Front Panel Window » Monitor, with a constant 1 for the first screen up to 8 for the eighth.
6. Invoke Run VI on each reference and leave the reference open. Do not close a reference that a running panel still uses.
7. Hand over the data path. Wire the queue reference through the display's connector, or let the instance obtain its named queue from the screen number the launcher passes in. The panel then loops on dequeue and redraws only when new data arrives.
8. Stop cleanly: enqueue a stop command to all eight queues, let each panel exit its loop, then close the references.

One queue per display

Give every display its own queue and keep the values outside the display. The panel is a view: it draws what the queue hands it and holds nothing between updates. The state lives in one place, and the queue serializes every write and read, so two views of the same data stay in step. That is what makes the template reusable: build the panel once and launch it per device, the same discipline as reusable HMI screens.

One data path feeding all the panels also keeps the load predictable. The main VI reads the source once per cycle and distributes one row per queue, instead of eight panels each polling on its own schedule; the same reasoning that puts one collector in front of HMI panels polling many PLCs. Queues are the usual tool here; notifiers and user events serve the same one-to-many purpose where a broadcast fits better.

Example: eight screens on one line

A plant wants one screen per cell along a packing line, 8 screens in total. The PC has 8 video outputs, the display settings number the monitors 1 through 8, and the main VI reads line data from a database.

Treat the timing numbers as inputs to measure on your own plant; the method holds when they change. The query returns one row per cell, 8 rows, and takes 150 ms. Writing one row to each of the 8 queues takes microseconds, so the cycle time is about 150 ms, and against a 1 s update target the loop keeps roughly 850 ms of margin (1000 ms − 150 ms). Each screen receives one fresh row per second.

The launcher passes each instance a single number, the monitor number, and the instance derives everything else from it:

Monitors 3 through 7 follow the same pattern: 8 instances and 8 queues in total, one per screen. Watch the 1 s target against the measured query time: if the query grows to 1.2 s the loop misses the target, and the fix is to trim the query to current values only, keeping history off the wall screens.

How to check it worked

Launch and walk the wall: monitor 1 shows cell 1, monitor 8 shows cell 8, and each panel sits on its own physical screen. Three checks catch the usual faults.

• Wire the error cluster from every property write and every Run VI invocation back to one error handler. A failed open then surfaces as an error, instead of a panel silently landing on monitor 1.
• Change one value at the source and watch two screens at opposite ends of the line: both should show the new value within one 1 s cycle.
• Reboot the PC with every output connected and confirm each panel returns to the same physical screen. If the OS renumbered the outputs, panels land on the wrong screens; correct the numbers in display settings and relaunch.

Recommendation: for any job from two monitors to the 8-screen line above, build one display VI template with no state, launch one instance per screen, write Front Panel Window » Monitor to the OS monitor number before Run VI, and give each instance its own queue named after that screen. Use the fixed window run time position setting only for a single panel whose screen never changes.

Questions