Ignition Features and Ideas

There have been a few times where the Ignition service needed to be restarted to resolve issues and I had to get IT involved to do the restart. It would be nice if the Ignition Service that runs in Windows (or other platforms) could be restarted from the Gateway Web Portal.

When ignition crashes, a crash log is generated in the ignition folder. When running Ignition in a container, we chose to only make the data and log directory persistent on disk. Therefore, when it crashes, we can see the issue in its log, but with the container restarting we lose access to the crash log it generated. Please either change the default location of the crash log to its log directory, or provide a solution to configure a customized crash log directory (config). Thanks. [Related case #190423]

Improvements to listing gateways in Ignition Designer Launcher such as reordering, sorting, small icons, list, or grouping. Especially needed when administrating many gateways

It would be really helpful to have shared Data Types between gateway platforms in Ignition Scale-Out Architecture. for example, if we have Pump UDT we could make an instance either on local tags folder or remote tag providers.

Provide a style for or other setting to custom color and don't size of popup, height of title bar and background color. It is important for theming.

Ignition binds a remote BACnet device only after it receives an I-Am. Per the BACnet standard, many devices answer a unicast Who-Is with a broadcast I-Am. On a subnet that has no BBMD, that broadcast never reaches the gateway (registered as a foreign device), so the device never initializes — even though it is fully reachable by directed unicast and is read without problems by other tools that use static device bindings. Request: a per-device "Static binding" option: given the Remote Address + Device Number, communicate by directed unicast ReadProperty/WriteProperty without requiring a broadcast I-Am to complete initialization. Why it matters: removes the hard BBMD dependency for devices whose IP and instance are known and static. We have ~20 devices across two BBMD-less subnets that are reachable by unicast but can't be brought online in Ignition today for this reason alone.

Details: The driver honors the device-advertised (or default) APDU and segment timeouts. Slow controllers time out during large or segmented responses, and the connection never stabilizes. The only override exposed today is Discovery Timeout, which only affects the discovery phase — not per-request APDU/segment timing — so steady-state reads still fail. Request: expose APDU Timeout, Segment Timeout, and retry count per device in the device connection settings (Advanced). Why it matters: slow devices simply need more time per request; a per-device override keeps them connected instead of dropping to UNINITIALIZED.

Details: The BACnet driver builds large ReadPropertyMultiple (RPM) requests. Small field controllers can't cope with them and the device never initializes: Controllers with a small response buffer return Abort(buffer-overflow) — they start a segmented reply, then abort mid-transfer. Slower controllers return Abort(application-exceeded-reply-time) — they can't compute all the values within the reply window. In both cases there is no automatic fallback — the same large RPM is re-sent every polling cycle and fails identically, so the device stays UNINITIALIZED/flaky. We hit this on a Siemens Climatix POL908 (IV Produkt AHU, 239 objects → exceeded-reply-time) and a Regin Corrigo (→ buffer-overflow). Third-party BACnet clients read these exact devices fine, because they read conservatively (small batches / single reads). Ignition can't currently match that. Request: a per-device setting for max objects/properties per RPM , and/or a "Force single ReadProperty" toggle. Bonus: on Abort(buffer-overflow / segmentation-not-supported) , automatically retry with a smaller batch or single ReadProperty. Why it matters: makes a large class of common controllers (Climatix POL6xx/POL9xx, Regin, etc.) readable without any device-side changes.

A watchdog-style alarm should be implemented to detect communication or data flow issues by monitoring the time elapsed since the last update of a tag or MQTT topic. The alarm can utilize the timestamp provided by MQTT Engine or be configured as a built-in alarm condition on a UDT reference tag that tracks the age of the most recent value update.

Currently when this happens the designer can revert any open perspective view being worked on to the saved version on the gateway automatically when connection is regained, erasing all changes that have been done since the last save. It would be nice if the user was at least prompted if they want this sync to occur or if they want to keep their local copy being worked on in the designer.