Resolving isAlarmActiveFiltered Errors in Ignition 8.3.0

On Ignition 8.3.0-beta4 (build b2025081810, Azul Java 17.0.15), every isAlarmActiveFiltered expression binding in Vision fails on the first evaluation. This includes the unmodified example from the manual. The cause is a platform bug, tracked as IGN-14301: the client-side RPC encoder cannot serialize the filtered-alarm request, so the request never reaches the gateway. Your tag paths, priorities and alarm configuration are not the problem. The fix is targeted for 8.3.1. Until then, move the alarm evaluation off the client RPC path or bind directly to the PLC alarm bits.

Exception chain in the expression binding error

Read the innermost Caused by line first. It is the only line that tells a platform fault apart from a configuration fault. The outer layers are generic wrappers. Error executing expression binding on UDT_Tank.UDT_Tank.ALM_ActiveCritical appears for any binding failure. Error retrieving alarm state from gateway sounds like a connectivity or permissions problem, but it is only the message the alarm function uses to wrap whatever broke beneath it.

The deciding line in this trace is:

java.lang.ClassCastException: class com.inductiveautomation.ignition.common.rpc.impl.AlarmingRpc$IsAlarmActiveFilteredRequest
cannot be cast to class java.io.Serializable
  at com.inductiveautomation.ignition.common.rpc.impl.AlarmingRpc$1.encode(AlarmingRpc.java:57)
  at com.inductiveautomation.ignition.common.rpc.proto.ProtoRpcSerializer.encodeValue(ProtoRpcSerializer.java:119)

A ClassCastException during encode means the failure happened inside the client JVM while it was building the outbound message. No network round trip took place. A bad path or a gateway-side fault looks different.

Deciding values and where to read them

The control test is the one that isolates the fault. isAlarmActive uses the same alarming RPC service and passes on the same client and gateway. That rules out session, permission and gateway alarm-subsystem faults. Only the filtered request type is broken.

Client-to-gateway RPC encode path in Vision

Vision clients and the Designer run expression bindings locally in the client JVM. Alarm state lives on the gateway, so an alarm expression function cannot answer from local data. Every evaluation becomes a remote call. The stack trace shows the whole path, in order:

1. VisionTemplate.startup starts the template's bindings. In this case that happened when the template was double-clicked open in the Designer.
2. ExpressionPropertyAdapter.runExpression evaluates the binding on the custom property.
3. ClientFunctionFactory$IsAlarmActiveFilteredFunctionClient.execute is the client-scope implementation of the function. It calls a proxy for the alarming RPC interface.
4. GatewayInterface.invoke hands the call to ProtoRpcSerializer.writeParameters to encode the parameters.
5. AlarmingRpc$1.encode casts the IsAlarmActiveFilteredRequest object to java.io.Serializable. It needs that cast to fall back to Java object serialization. The class does not implement that interface, so the cast throws.

The failure is deterministic. It does not depend on load, timing, tag count or alarm state, because the exception fires before a single byte leaves the client. Every binding that calls the function fails on every evaluation. A template with four priority properties produces four identical errors.

The 8.3 line changed how client-gateway RPC messages are encoded. That is why an expression that runs cleanly on 8.1.48 breaks here without any edit to the project. The upgrade exposed a request type that the new encoder was not built to handle.

Version and function scope of IGN-14301

Treat the whole 8.3.0 release as affected unless its release notes list IGN-14301 as resolved. Check the release notes of each 8.3.x build for that ticket number before you revert any workaround.

Workaround procedure for PLC-evaluated alarm UDTs

In this architecture the alarms are evaluated in the Rockwell PLC by an alarm AOI. The UDT exposes four discrete bits: high-high, high, low and low-low. It also carries the process value and setpoints. Each Ignition alarm is a digital alarm on one of those bits. The template then uses one property per priority, each bound to a variant of:

// Check if there is a critical alarm active belonging to the
//   analog alarm UDT
isAlarmActiveFiltered({UDT_Tank.UDT_Tagpath} + "*", "*", "*", 4, 4, 0, 1, 0)

The priority window 4, 4 selects Critical only. The trailing three flags control the shelved/acknowledged/unacknowledged filtering. Confirm their order and meaning against the function page in the Ignition manual for your version. You need that meaning to reproduce the same filtering in a workaround.

Option A — direct bit binding. Use this when the indicator only needs to show whether the PLC condition is active.

1. In the UDT definition, find which member bit carries the alarm that is configured at each Ignition priority. The mapping is whatever your alarm configuration sets. Read it from the alarm properties on each bit member rather than assuming high-high is Critical.
2. Rebind each template priority property to an indirect tag binding on that member, built from the template's UDT parameter.
3. If one priority covers more than one bit, use a boolean OR of those members in an expression binding. Tag references are local reads, not alarm RPCs, so they are not affected by the bug.

Option B — gateway-evaluated member. Use this when shelved and acknowledged alarms must still suppress the indicator.

1. Add a Boolean expression member tag to the UDT for each priority, for example one for active Critical.
2. Put the same isAlarmActiveFiltered call in the member's expression. Build the path from the UDT instance path parameter so it covers that instance's members.
3. Expression tags execute on the gateway, not through the Vision client's encode path in the stack trace. Before you roll this out, confirm on your 8.3.0 build that the member evaluates without a quality error.
4. Rebind the template properties to these members with ordinary tag bindings.

Options A and B both give you one template that runs on 8.1.48 and 8.3.0 gateways without per-version edits. The 8.3 alarm metrics features are the long-term replacement for this pattern. They do not exist on 8.1, so a mixed fleet still needs a version-neutral binding.

Template behavior checks after the change or upgrade

1. Open the template in the 8.3 Designer. Confirm that no error overlay or exception dialog appears on any of the four priority properties.
2. Launch a real Vision client and repeat the check. The Designer and the client share the client-scope code path, but the launched client is what operators see.
3. Force each PLC alarm bit in turn, from the controller or a test routine. Watch only the matching priority property go true, and confirm the other three stay false.
4. With a bit active, compare the template indicator against the Alarm Status table filtered to the same UDT instance. A mismatch points to gateway alarm state, not the binding.
5. For Option B, shelve and acknowledge an active alarm. Confirm the indicator follows the filter flags the way it did on 8.1.48.
6. After you move to 8.3.1, check the build in the gateway status page. Restore the original isAlarmActiveFiltered binding on a copy of the template, then repeat steps 1 through 5 before you replace the workaround fleet-wide.

Recurring pitfalls in filtered alarm bindings

• Curly quotes. Expressions copied from web pages or word processors often carry typographic quotes around *. The expression parser only accepts straight ASCII quotes. This produces a parse error, which is a different symptom from IGN-14301. Retype the quotes before you chase anything else.
• Wildcard overreach. Appending "*" directly to an instance path matches every sibling whose name starts with the same string. For example, a pattern built for Tank1 also matches Tank10 through Tank19. Append the path separator before the wildcard so the pattern only covers that instance's members.
• Misreading the wrapper message. Error retrieving alarm state from gateway sends engineers toward gateway network and security settings. On this bug the gateway never receives a request. Trust the innermost exception, not the wrapper.
• Empty gateway alarm state. A separate 8.3 issue, IGN-14308, covers UDT member alarms that do not always populate when active. If a working binding returns false while the PLC bit is true, check whether the alarm appears in the Alarm Status table at all before you edit the expression. Option A is immune to this because it reads the bit directly. Option B is not.
• Beta builds in production. 8.3.0-beta4 is a pre-release build. Validate alarm templates on a test gateway and keep production on 8.1.48 until the release that fixes IGN-14301 has passed the checks above.

FAQ