Ignition Features and Ideas

With an embedded view, it would be nice to be able to create a drop-down list for the necessary parameters. For example, if you create a typical and you have 2 options as parameter, it would be useful to be able to display this via a drop-down list so that the user does not have to open the embedded view to know what he can enter.

it would be nice if in the tag path, the tag provider at the start of the path,in brakets e.g.( [provider]tag1 ), was parametrizable from the project settings and bindable to the default tag provider of that project. Our use case is that we have a number of machine with similar ignition project, and each machine has its own tag provider. if the tags in our transaction groups were set to the deafult tag provider of each project, it would be much faster beacuse the tag structure is similar for each project.

Like Vision Tab Strip, allow Perspective Tab Container to support orientations of Top, Left, Bottom and Right.

In Ignition SCADA, when projects have a large number of UDT (User-Defined Type) instances, and each tag contains event scripts, performance issues become noticeable during tag editing, applying changes, and especially at gateway startup. The current compilation process for these scripts contributes significantly to slowdowns, as Ignition recompiles all event scripts for every tag, regardless of whether they have changed. Impact: -Projects with extensive UDT usage experience long delays when applying changes. -Gateway restarts take significantly longer, affecting system availability. -Development workflow slows down, making iterative changes cumbersome. Suggested Improvement / Feature Request: -Optimize the startup tag change script compilation process to reduce unnecessary recompilation for unchanged tags. -Provide progress indicators or background compilation to improve developer experience during large project deployments. This feature would greatly improve performance, scalability, and usability for Ignition projects with complex UDT structures and numerous event scripts.

I need to have dynamic min/max properties on tags, i.e. min/max tag properties should be bindable to other tags.

Currently we can only send alarms to an Alarm Journal on "Display path" or "Alarm Source" which is extremely limiting. Alarm Source is effectively just based on how you structure your tag provider folders, and Display Path can literally be anything. We've built lots of filtering on the various alarm components to utilize the alarm associated data properties. These may contain plant location, machine name, tag type etc... and would be a much more flexible way to split out alarms into different journals. Not all alarms will necessarily have the associated data property configured in the journal, but in that case it generally makes sense to allow us to bring it through or exclude it by default. Due to the nature of Ignition having tag providers accessible to all projects across the gateway, it would be nice to ensure distinctly different projects have an easier way to include / exclude alarms in their own journals based on properties we choose.

Currently, the Perspective login screen is not project-based, which means dynamic control via session.props.theme is not possible. The login screen inherits static Gateway branding (logo, colors, etc.), and developers have no access to override or apply project-level themes. This limitation prevents the login screen from following runtime theme changes such as night mode, leading to inconsistent user experience across HMI projects. It would be useful if the login screen could inherit project-level or session-based themes to ensure consistent styling across all views.

Right now, I have a bunch of devices using older protocols like Modbus, BACnet, and DNP3. But I'm adding more and more new PLCs and gear that use OPC UA. The issue is, all the Modbus/BACnet/DNP3 stuff shows up on the main 'Device Connections' page, but the new OPC UA stuff is tucked away in its own 'OPC UA Connections' section. Back in the day, when OPC UA was mainly just talking between big servers, this setup made sense. But now, it's used right down at the PLC and field device level, so those OPC UA endpoints are basically just another "device." I think it would be way easier if we could just list those OPC UA connections under the main 'Device Connections' page, and let us add them using the 'Create Device Connection' button, too. Maybe we could add a simple checkbox on the OPC UA connection setup that says something like, "List this as a Device instead of a Server." That would make the whole system much cleaner and easier to manage!

When activating a license from EAM you cannot send in a license when the target system is in 'trial expired' mode. This is particularly annoying because when you remove a license using EAM the agent immediately plunges into trial expired mode and you need to visit it anyway.

Perspective message handlers currently must be referenced by manually typed string names. This creates avoidable human errors, especially in large projects where many views define different handler names. I would like a feature that allows developers to view, browse, or auto-complete all message handlers in a project—similar to how tags or properties are discoverable. Even a simple scripting function like system.perspective.listMessageHandlers() or editor IntelliSense support would greatly improve reliability and reduce maintenance effort.