Show a CODESYS WebVisu fullscreen in Chromium kiosk mode

Why the board has no TargetVisu

TargetVisu is not supported on the single-board runtime. A project that asks for it downloads without an error, runs, and shows nothing on the attached screen. An error-free download with no picture points here first, before cables and panels.

The display path this runtime has is the web visualization. While the runtime runs your application, it serves the visualization on TCP port 8080 at the page name webvisu.htm. Any browser that reaches the board can open it, and a browser on the board itself needs no network at all. From version 3.5 SP6 the web visualization accepts multitouch input as well, which the last section puts to use.

What you need

• The board running the CODESYS runtime, with your project downloaded and started.
• A screen attached by HDMI, with touch returned over USB. An ordinary HDMI touch panel is enough for the picture; for gestures the panel must report more than one contact, which the multitouch section covers.
• Three packages: chromium to render the page, x11-xserver-utils for the xset blanking commands, unclutter to hide the mouse cursor.
• sudo rights, and the autostart file of the LXDE desktop session: /etc/xdg/lxsession/LXDE-pi/autostart.
• Chromium as the standard browser. It takes command line flags, which kiosk mode needs, and it renders the HTML5 canvas the visualization draws on.

The autostart lines, in order

The autostart mechanics behind these lines, including what the leading @ does on a browser line, are covered step by step in Set up chromium kiosk autostart on a Linux panel. This section adds the WebVisu parts: the page address, the blanking lines, and the one file that fires on the board.

1. Confirm the runtime is serving before touching the desktop. From a laptop on the same network, open http://<board-ip>:8080/webvisu.htm. If the visualization renders there, the CODESYS side is done and the rest of this page is display setup. If it does not, stop and fix that first; no autostart line can show a page the runtime is not serving.
2. Install the packages: sudo apt-get update && sudo apt-get install chromium x11-xserver-utils unclutter.
3. Open the autostart file with sudo: /etc/xdg/lxsession/LXDE-pi/autostart. Two folders sit under /etc/xdg/lxsession, LXDE and LXDE-pi, and edits to the LXDE file leave the board's own session untouched. That mismatch is why autostart lines so often appear to do nothing. While the file is open, comment out the screensaver line already there.
4. Add four lines to the end of the file:

xset s off
xset -dpms
xset s noblank
chromium --kiosk --incognito http://localhost:8080/webvisu.htm

The line xset s off stops the screensaver timer, xset -dpms stops DPMS, the display power-down signaling, from switching the panel off, and xset s noblank forbids forced blanking. The last line starts Chromium with --kiosk, which renders fullscreen with no toolbar or address bar, and --incognito, which keeps profile and restore prompts out of the way after a power cut. The linked guide above shows the leading @ prefix that relaunches a browser line if it exits.

5. Reboot. The desktop should never appear, and the visualization should fill the panel edge to edge.

These lines govern the desktop session only. Boot messages that scroll past before the desktop starts are their own job, covered in Show only a splash screen on an embedded Linux kiosk boot. On releases that ship the Wayfire desktop instead of LXDE, the file above does not exist and the lines belong in that release's own autostart; Why your wayfire autostart is not working shows where they go.

How to check it worked

• Picture: the visualization fills the screen edge to edge, with no taskbar and no address bar.
• Data: force a variable in the running program and watch the element respond. Screen changes driven from the program are covered in Change HMI screens from the PLC and give control back.
• Blanking: leave the panel untouched for 10 minutes. It must stay lit. If it blanks, one of the three xset lines is missing or sits in the other lxsession folder.
• Stale images: if values move but an image stays old, the web visualization's bitmap cache is holding it. NumCachedImages 0 for live WebVisu bitmap updates gives the cache setting that lets bitmaps refresh while the page runs.
• Nothing on screen: reopen the page from the laptop as in step 1. If it renders there, the fault is in the autostart file, usually the wrong folder. If it does not, the runtime is not serving, so the project is not downloaded or not started.

Example: sizing the text on a 10 inch panel

A packing station gets a 10 inch HDMI touch panel at 1280 × 800 pixels, mounted so the operator reads it from 4 ft. The FHWA legibility planning figure gives 30 ft of viewing distance per inch of capital letter height, with 20 ft per inch as the safer figure for fast reading. At 4 ft the minimum capital height is 4 ÷ 30 = 0.13 in; for labels read at a glance, hold 4 ÷ 20 = 0.2 in, which is 5 mm.

Convert that into pixels for the visualization editor. A 10 inch diagonal at 1280 × 800 is a 16:10 panel 8.48 in wide (10 × 16 ÷ √(16² + 10²) = 8.48), so it packs 1280 ÷ 8.48 = 151 pixels per inch. A 0.2 in capital is therefore 0.2 × 151 = 30 pixels tall, and line spacing at 1.7 × 5 mm = 8.5 mm keeps the rows apart.

The result moves with the panel in a predictable direction. The same 30 pixel label on a 14 inch panel at the same 1280 × 800 resolution sits on a panel 11.87 in wide, 1280 ÷ 11.87 = 108 pixels per inch, so it measures 30 ÷ 108 = 0.28 in and reads out to 0.28 × 20 = 5.6 ft. Same pixels on a bigger panel means larger text.

Draw the labels at 30 pixels of capital height and the buttons at that height plus padding for a fingertip, and the panel reads cleanly at 4 ft.

What multitouch does on an attached panel

From version 3.5 SP6 the web visualization accepts multitouch input. The gestures were shown working from tablet browsers that opened the same page over the network: pinch, flick and moving two sliders at once. The same page on a locally attached HDMI panel behaved differently: taps worked and a single slider moved, pinch and swipe did nothing, and Chromium's extra touch flags did not change it.

The limit sits below the browser. A touch panel that reports a single contact cannot feed a gesture to any browser, and small HDMI panels commonly report exactly one. Check the panel's specification for multi-finger reports before promising gestures on the mounted panel.

So build the panel visualization for taps and single-element moves, and keep pinch, flick and multi-slider gestures for tablet clients, which reach the same visualization at http://<board-ip>:8080/webvisu.htm. If the panel should sleep when the line is idle and wake on a touch, that is a separate setup: Turn an idle HMI screen off after 30 seconds and wake it by touch.

Recommendation

Recommendation: serve the visualization from the runtime and render it in Chromium kiosk mode on the attached panel. Install chromium, x11-xserver-utils and unclutter, put the four-line block in /etc/xdg/lxsession/LXDE-pi/autostart with the screensaver line commented out, reboot, and hold the panel to a 10 minute untouched test. Draw the visualization for single touch, size the capitals to the real viewing distance on the 20 ft per inch figure, and reserve gestures for tablet clients on port 8080. One boundary to keep: an operator visualization is an operator view, not a safety function, so emergency stops and interlocks stay wired to the machine's own safety hardware.

Questions