The built-in page server on an HMI panel publishes the screen itself: it reads the tag values, draws the screen and sends a JPEG. That is why the browser never sees text, why %VER% prints a version while a tag name prints none of what you want, and why the load is slower when the screen is not already displayed. Real text needs a separate read-only page.
A panel's built-in web server publishes its screens as pictures. When a browser opens the page, the panel reads the tag values it needs from the PLC, draws the screen, encodes it as a JPEG and sends the image. The browser receives pixels, never characters, so nothing on the page can be selected, copied or searched. The %VER% token in the default index.html is one of 11 built-in panel-information tokens on that panel line; it prints a firmware version and has no counterpart for project tags. When customers need real text, the sound architecture is a small read-only service that reads the tags itself and serves its own page. Measure the load time first, because the panel takes a longer path when the requested screen is not the one it is already showing.
Why does the HMI web page show a picture of the screen instead of text?
Because the page server publishes the panel's own rendering: it reads the tag values from the PLC, draws the screen, encodes it as a JPEG and sends the image, so the values reach the browser as pixels and never as page text.
The HTML around the image is yours. The data is in the image. That makes the project screen the data format: to change what customers see, you edit the screen, and a browser gets the new picture on its next request.
Two other faults get blamed on this design. When the picture arrives but a value reads zero, that is a tag problem, covered in why an HMI web server shows zeros for PLC tags. When the page lists fewer screens than the project contains, that is a list limit, covered in why an HMI web page shows only 10 of your screens. A slow picture is neither. It is the normal cost of serving screens as images.
Why does %VER% work in the default page but my PLC tag does not?
%VER% is a fixed token the server replaces with its own firmware version before the page goes out; the token list on this panel line holds 11 entries, and every one of them reports panel information, so there is no slot for a project tag.
The default index.html ships with the panel and uses %VER% to print the version at the foot of the page. The other tokens report the same class of fact: things the panel knows about itself. None of them reaches into the project tag database.
Writing %TankLevel% beside %VER% copies the pattern without the mechanism: the server replaces only the tokens in its list. What an unknown token prints is not documented, so test it on a scratch page if you want the answer for your firmware. The documented answer for the panel line is plain. The web-server setup help for the current generation still lists 11 tokens, all panel information, among them the version token, and tag embedding is absent from that list.
Why does the JPEG load slowly when the screen is not shown on the panel?
Because the panel runs extra steps before the image exists: with the requested screen absent it must fetch tag values from the PLC and build the screen, then encode the JPEG and send it; that fetch-and-build step is skipped when the screen is already shown.
Two load paths, then:
- Panel already showing the requested screen: encode the JPEG and send it.
- Panel showing something else: fetch the tag values from the PLC, build the screen, encode, send.
The extra time therefore has four homes: the panel-to-PLC read, the screen build, the JPEG encode, and the transfer plus browser decode. The browser shows you one total for all of it. Measure the two states and take the difference; that difference is the fetch-and-build cost, and the lower number is encode, transfer and decode together. If both states are slow, the transfer is the suspect: the developer view in any browser prints the image size and the transfer time.
How do I measure where the delay comes from?
Load the same URL twice on the plant network, once with the panel already showing that screen and once with a different screen, three to five loads each, and record every load time; the gap between the two averages is the panel's fetch-and-build time.
- Set the acceptance target first. For a status overview a customer opens occasionally, 5 s from request to full picture is a sound target. Tighten to 3 s only if the page will be watched during a production run.
- Park the panel on the overview screen. Load the URL three to five times, waiting for the full picture each time, and record every value.
- Navigate the panel to its normal operating screen and repeat the same loads.
- Average both sets. The difference between the averages is the fetch-and-build cost.
- Open the browser's developer view, find the image request, and read its size and transfer time to see how much of the lower average is the network.
Example: a 5-second target on a 40-value overview screen
An overview screen carries 40 tag values. The target is 5 s from request to full picture, and the customer sits on the office network.
Panel parked on the overview screen, three loads: 2.1 s, 1.9 s, 2.0 s. Average: (2.1 + 1.9 + 2.0) / 3 = 6.0 / 3 = 2.0 s.
Panel on its operating screen, three loads: 6.4 s, 7.1 s, 6.9 s. Average: (6.4 + 7.1 + 6.9) / 3 = 20.4 / 3 = 6.8 s.
Difference: 6.8 s - 2.0 s = 4.8 s to fetch and build 40 values. Against the 5 s target, 2.0 s passes and 6.8 s fails. The 40 values and the timings are example inputs for the arithmetic; your measurements decide your case.
The decision follows the numbers. The JPEG meets the target only while the panel sits on the overview screen, and an operating panel is needed for operating. Publish the values as text through the separate interface and keep the JPEG as the picture of record.
Is there a supported way to get tag values as text into the browser?
Not from this panel line's page code: the 11 tokens it accepts all report panel information, and tag embedding in the page has no documented implementation here, so text has to come from a documented feature on another panel line or from your own interface.
What exists, by name:
- The token list. Panel information only. Open the web-server setup help for your model and count the entries; 11 entries of panel information is the whole supply.
- A documented attribute on other panel lines. Some current panel software documents an HTML attribute, written
data-ix-, whose value you set to a tag name; the served element then carries the live value as text. That is a feature of those products, worth asking about if a panel purchase is on the table anyway. - Platforms where the HMI is a web application you write. There the page is your own HTML, CSS and script talking to the controller, and text needs no token at all.
- What stays a wish: a file of every tag and value in the server's root, refreshing every 3 to 5 s. That request comes with this question every time it is asked; put it to your vendor, and build only against what the documentation prints.
For getting values that a panel page does carry, and for proving where a wrong one comes from, see reading PLC tag values from an HMI panel web server.
What should I publish instead when customers need selectable values?
Serve your own page from a small read-only service that reads the tags over the same PLC link the panel already uses; customers open your page, the panel keeps its JPEG for whoever only wants the picture, and neither path loads the other.
Rules that keep it safe and simple:
- Read-only. Writes stay on the panel or behind a controlled interface, never on a page a customer can open.
- Only the intended values. Publish the overview numbers the customer asked for, not the project's whole tag list.
- Secure transport. Use the documented secure HTTP setup for whichever server faces the customer, and keep the page on the office network with one read-only path across to the controller. A page strangers can open on the control network is a window into the plant, and it stays shut by design, not by luck.
That last point is the one safety rule in this job.
How do I verify the customer-facing page before release?
Run the acceptance test in both panel states, check the published values against the live panel, and load the page from the customer's own network before you call the job finished.
Four checks, in order:
- Load time in both states against your target, using the two-state measurement above.
- Value agreement: pick a value you can make move, watch it change on the panel, then check the page shows the new value inside your target time.
- Text really arrives: view the page source or select a value with the mouse. Selectable characters are the requirement; a legible number inside an image is pixels.
- Exposure: open the page as an anonymous visitor and confirm only the intended values appear.
Opening the page from outside the building brings its own limits, covered in what to check when the HMI web page loads but remote access is missing.
Recommendation: Keep the JPEG overview when customers read it with their eyes and the measured load meets your target in both panel states. Put a read-only page of your own in front of the tags the moment anyone needs to select, copy or count a value, and skip the day of trying to turn %VER% into a tag template: the 11 tokens are panel information, and text is a different interface, not a cleverer page.
Questions
Does the JPEG update by itself when a tag value changes?
No update interval is documented for the served image. The page shows the values the panel read at the moment of the request, and a new image arrives when the page is reloaded. Each reload repeats the same path, including the fetch-and-build step when the requested screen is not the one displayed. For anything close to live, the reload has to come from the customer's side or from your own page.
Is a legible number inside the JPEG good enough for customers?
For someone reading the overview with their eyes, yes, and the picture is a fine status board. For anything that copies, searches or counts the values, no: the number exists only as pixels, and selecting it in the browser selects part of an image. A scheduled e-mail with the values written into the text is a workable report between the two, as long as nobody treats it as a live page.
What exactly should I ask the panel vendor for?
Ask for the page-code token list for your exact firmware, and whether a documented HTML attribute or data export puts tag values into served pages. The list itself answers you: 11 entries of panel information means text is out. Ask also whether the documented secure HTTP setup applies to your model, because a customer-facing page should not ride on plain HTTP.
Can I write my own web page that reads the PLC directly?
Yes, and that is the supported path when customers need text. A small service on the plant network reads the tags over the same link the panel uses and serves its own HTML, so the browser talks to your service and the panel stays out of the chain. Keep the service read-only, expose only the values customers need, and test it from the customer's network before release.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.