Ignition Features and Ideas

I have lost progress on projects and not been able to trace issues because Project Auditing was not enabled or configured correctly. I suggest a Gateway Setting to "Enable Default Project Auditing" and if enabled an Audit Profile selection. If set, any new project would be created already recording to the selected Audit Profile.

In scenarios where we may have multiple designers opened that are connected to unique gateways but happen to share the same project name and same gateway name yet differ by deployment mode (e.g. "dev" and "qa"), it would be nice to have the deployment mode also displayed at the top. Currently I have to dig down to the System tag provider in the tag browser to find the deployment mode tag to differentiate the two. The title could look something like: <Project Name> - <Gateway Name> | <Deployment Mode>

Symptom: Table object's selection is stuck after a refresh in the browser. Selected row and selected dataset holds the last value from before the refresh, and resetting these properties does not work. Setup: Table object, query binding that returned dataset with 3 columns. Row selection and multiple interval selection are enabled. Four columns are configured in column properties. The fourth uses a custom view to show a calculated status, with 'field' set to 'column_4', which does not exist in the dataset. The view has a parameters bound to the implicit 'value' and 'rowData'. Suspicion: Table object fails when 'value' is null/undefined for a column whose field isn’t in the dataset. This seems to leave the table’s selection state stuck after a refresh.

Support more formats than RGB/HSL types - Such as OKLAB. This is already technically possible, but giving it a picker like RGB has would be nice.

It would be great for the tag report tool to include the option to include tags with configured alarm pipelines.

Requested Enhancement: Provide a configurable pre-login challenge/token timeout. Alternatively, automatically refresh or renew the challenge/token while the login page remains open. Allow administrators to define an appropriate timeout based on operational requirements and security policies Details : Currently, the Perspective pre-login authentication challenge/token has a hardcoded ~5-~15 Min timeout that cannot be configured. Once the login page remains idle beyond this timeout, users can enter valid credentials but receive an HTTP 400 error on the /next-challenge request. The user must manually refresh the login page before authentication can proceed successfully. This behavior has been reproduced in both web browsers and Perspective Workstation and has been confirmed as the current expected product behavior. Additional Notes: This functionality should be independent of the existing Perspective Session Inactivity Timeout setting. Increasing the session inactivity timeout does not prevent the pre-login challenge from expiring. The current behavior can lead to failed login attempts and user confusion when login screens remain open for extended periods before authentication.

Are there any plans to add a dark theme to the ignition designer? I see that this question has been posted a few years ago but its 2020 now so I thought I would ask again.

I'm generating some reports and saving them to a database. I'd also like to save the data used to generate the report, so it can be used in downstream analytics. It would be helpful if system.report .executeReport returned both the binary report and the data dict used to construct it. My workaround is going to be to save the data object to the database as the last script in the Data tab of the report, then update that row with the report binary in the caller. That's approach is a little trouble prone.

Context We run medical-device manufacturing applications on Ignition 8.3. We maintain an ISA-95-based UDT library (with some domain-specific additions) in Git and deploy it to all gateways from Azure DevOps. New equipment gets the library's UDTs and publishes consistently to our UNS. Problem UDT definitions are shared by every project that uses the same tag provider. When a definition changes, every instance changes immediately, including instances used by validated applications that we cannot change without formal change control. In regulated environments this makes it hard to evolve a shared UDT library safely. Current workarounds (and why they fall short) Version in the tag path (e.g. .../Fiducial/V1.1/Fiducial1) Separate tag providers per UDT version Both result in different tag paths per version, duplicated data, and significant maintenance in each application and in the UNS. Deployment mode (8.3) covers part of the deployment story, but not the need to keep multiple definition versions side by side on the same gateway. Proposed feature Allow multiple versions of a UDT definition to exist side by side on the same gateway. Let a project (or gateway configuration file) pin which UDT library version it uses. Instances only receive definition changes when they explicitly opt in to a newer version. Tag paths stay stable regardless of which definition version is used. Ideally, definitions can be sourced from a Git-backed library in a text/diff-friendly format. Benefits Validated applications stay unchanged until they go through change control. One shared UDT library across all gateways without forking tag paths or providers. Clean, reviewable change history for UDTs in source control. Consistent UNS structure across versions. Ref: support ticket #199606

Give an option for scaling a tag via an expression directly from a read. Often I need to convert a tag from native units (deg C to deg F) or an odd combination of mathematical operations to convert the tag into the units/format desired. Currently have to do a direct tag read and then create another expression tag to then convert that "raw" value. Giving an expression option (in addition to the current, linear and other options) would eliminate a step and clean this step up and give much more flexibility to scaling.