Fix a dashboard image point that will not display

Match the symptom to the likely cause

Use the browser's network panel to separate these failure modes:

• The requested URL ends in a filename under the dashboard's template directory. The binding probably supplied a relative filename rather than an image endpoint.
• The response contains a page header, navigation or login form. The request reached an HTML page, possibly after a redirect, rather than an image response.
• The request returns an authentication or permission error. The image route may require a session or access rights that this dashboard request does not have.
• No image request appears. Check the bound variable, its capitalization, the image element and any browser security error.
• The request reaches the expected image route but returns not found. Check the point identifier, stored image reference, retention and documented request format. A missing route is another possibility.
• The image displays but shows an old capture. Retrieval works, but acquisition, timestamp handling or caching still needs investigation.

A broken-image icon alone cannot tell you which layer failed. Record the actual request and response before changing the dashboard.

Confirm that the dashboard binds the intended point

Check the point lookup before investigating image storage. Compare the identifier in the dashboard markup with the identifier returned in the point object. Do not assume that a similar display name identifies the same point.

Also compare the variable names exactly. A difference in capitalization can leave one expression reading an undefined variable while another expression displays valid metadata. Keep the point binding and the image expression consistent.

Inspect these fields through the platform's supported diagnostic view:

• The point identifier and data source.
• Whether the point is enabled.
• Whether its configured data type is an image.
• The current value and its timestamp.
• Any acquisition or validation error.

A populated point object proves that metadata reached the dashboard. It does not prove that the browser has received the image itself. A value such as capture-42.jpg may identify a stored file without exposing where or how an authorized client can retrieve it.

If the image value is absent or acquisition has failed, resolve that problem first. Changing the dashboard's image URL cannot create a capture that the data source never stored.

Distinguish the filename from the image endpoint

A browser resolves a relative filename against the page's base URL. If the dashboard supplies only a filename, the browser may look beside the dashboard template even though the platform keeps image-point data elsewhere.

An ng-src binding can insert the supplied value into an image request. It does not discover private storage, add the required point identifier or select the platform's image-serving route.

Use the manufacturer's documentation for the installed release to identify the supported retrieval method. If the platform has a working built-in image view, inspect its image request while signed in with an authorized account. That request can help identify which documented mechanism the view uses.

Check whether the request depends on:

• A point identifier, an image identifier or both.
• A current-value request or a historical timestamp.
• The application's deployment path.
• Session credentials or another documented authentication method.
• Permissions on the point or its data source.

Treat a captured request as diagnostic evidence, not proof that an undocumented internal route is a supported integration interface. Confirm the route before building a dashboard around it. Do not copy session tokens into templates or publish private storage paths.

Check what the server actually returns

Inspect the response, not just the URL shown in the image element. A successful HTTP status can still accompany a login page or an application shell.

For the failing request, check:

• Final destination: did the request redirect to a login page or another application route?
• Status: was the response successful, denied or not found?
• Content type: does the server identify the response as an image rather than HTML or JSON?
• Response preview: does it show the expected capture, a page or an error message?
• Browser console: was loading blocked by the page's content policy or by an insecure image request from a secure page?

If the endpoint works in a separate tab but fails inside the dashboard, compare the request context. A different origin, session handling or browser security policy may explain the difference.

Use the documented deployment and authentication configuration to correct that mismatch. Do not disable access checks or browser security protections to make the image appear.

Verify image support for the installed version

A REST API that returns point metadata does not necessarily provide image retrieval. Support for numeric values, text values, current images and historical images can differ between releases.

Check the documentation and release notes for the exact installed version and relevant dashboard module. Look for an explicit image-value response or a documented image-serving endpoint. A filename in a JSON response is not evidence that the API can return the corresponding file.

An announced feature is not evidence that your installation contains it. Likewise, an example from another release may use a route or storage mechanism that your release does not support.

If image retrieval is unavailable through the dashboard API, use a documented built-in image view or another supported integration method. Ask the manufacturer or its authorized support channel to confirm the path. Plan any required upgrade through the approved maintenance process rather than copying internal server code into the dashboard.

Correct the binding without mixing rendering layers

Once the supported retrieval method is clear, make the smallest necessary change. Correct the point lookup and variable name first. Then build the image request using only the documented parameters for that installation.

Do not paste server-side JSP expressions into a browser-rendered dashboard template. Server-side expressions run only where the server processes that template type. In ordinary client-side dashboard markup, they do not become executable server logic.

Changing an image filename to a page extension also does not convert a page into an image endpoint. If the response contains application navigation, you have requested a rendered page rather than raw image content.

Keep image access under the platform's existing authorization controls. Do not solve the display problem by copying private captures into a publicly accessible directory. That changes access to the data rather than fixing the retrieval path.

Check the repaired image and its freshness

Verify the completed change from the dashboard, not only from a separate browser tab. Use an account with the permissions intended for that dashboard.

Confirm that the intended point produces an image response, that the capture matches its timestamp, and that a subsequent capture appears through the supported update mechanism. Check how the view behaves when the session expires or no image is available. An old image should not be mistaken for a current observation.

If loading works but the capture remains behind the source, investigate factory screen update delay separately. Acquisition timing, image retrieval, browser caching and dashboard refresh are distinct parts of that investigation.

The repair is complete when the dashboard retrieves the intended image through a supported, authorized route and makes its age clear. A process photograph is useful context, but it should not replace the machine's protective functions or required process measurements.

Questions