Ignition Word Display: Convert on Publish, Not in the HMI

After the document workflow is fixed, the operator opens a stable PDF or HTML rendition in Ignition while engineering maintains an editable source. The key separation is between authoring format and operator display format: Word remains useful for editing, but the screen receives a format its viewer can render predictably.

What is the screen telling you?

Start with the operator-visible result. Determine whether the screen shows the document, downloads it, opens another application, displays stale content, or fails to load anything. That observation identifies the next layer to inspect.

A Word file is an authoring package, not a universal screen-rendering format. An Ignition component can pass a file location correctly while the client still has no renderer for that file type. What the screen is telling you is whether the failure occurs before retrieval, during format handling, or after publication.

Does the tag resolve to the correct document?

Read the value that selects the document at runtime. If it points to the expected file or database record, the tag is right; the binding is wrong when the display component receives another value, adds an incorrect path, or targets an unsuitable viewer. If the value itself is wrong, trace the controller value, driver data, tag expression, and document lookup in that order.

Capture both the logical document identifier and its resolved location. Avoid using only a filename as proof of revision: replacing a file under the same name can hide whether the client received the new content. A revision field, publication timestamp, or content version gives the operator interface a value it can display and audit.

Should the operator receive PDF or HTML?

Both configurations work, but they solve different problems. Convert Word to PDF when engineering wants to retain Word as the authoring tool and operators need a fixed rendition. Store editor-generated HTML when revision control, acknowledgements, media, and application-managed publishing matter more than preserving the Word file workflow.

For the smallest change to the existing workflow, use Word for editing and generate PDF for Ignition. For a managed work-instruction or SOP system, HTML is the stronger configuration because the application can associate content with editor identity, revision history, retraining actions, and operator notification. A WYSIWYG editor such as TinyMCE can accept content pasted from Word while retaining formatting, then generate HTML in the background.

Is conversion occurring at the correct workflow boundary?

Conversion belongs in the publication path, not in the operator’s viewing action. Install LibreOffice on the system assigned to publication and invoke the Writer command-line conversion from a controlled script:

lowriter --convert-to pdf

The script must receive the approved Word source, produce a PDF, and publish that result to the location referenced by Ignition. Separate draft storage from the published location so an incomplete edit cannot become an operator instruction merely because somebody saved the Word file.

1. Save the editable Word source in the engineering document location.
2. Approve the revision using the site’s document-control process.
3. Run lowriter --convert-to pdf against the approved source.
4. Confirm that conversion produced a readable PDF before replacing the published copy.
5. Publish the PDF and update its revision metadata as one controlled operation.
6. Signal the Ignition view to reload the document or select the updated revision.

If text-friendly change tracking is required, LibreOffice “Flat” file formats can be placed under version control. Setting PrettyPrinting = true in the advanced document-save settings makes those files more suitable for reviewing changes. This affects the editable source workflow; operators can still receive PDF.

How do you prevent stale or uncontrolled revisions?

A shared Word file simplifies editing but does not by itself answer who changed it, what changed, whether approval occurred, or whether operators require retraining. Treat those as publication data rather than properties inferred from the filename.

For HTML storage, save the editor output as a string in the database and keep revision metadata in associated fields. For PDF publication, record the revision beside the generated file and display it on the Ignition screen. In either design, operator access should target only the approved revision.

How do you verify the resolving branch?

1. Select a known document from the same controller state and Ignition tag path used in production.
2. Read the final component binding and confirm that it resolves to the approved PDF or HTML record.
3. Open the document from an operator client and inspect headings, tables, pagination, embedded media, and special characters used by the procedure.
4. Make a controlled source change, advance its revision, publish it through the selected workflow, and reload the operator view.
5. Confirm that the screen shows the changed content and the new revision while the previous approved revision remains traceable.

If the path and revision change but the content does not, inspect caching and reload behavior. If the published output itself is old, inspect the conversion input and publication transaction. If the output is current but the tag selects another record, return to the controller-to-tag-to-binding chain.

Frequently asked questions