[Bug - 16356]Derived Tags for Bit usage

Hi, I’m using Schneider Electric M241/M251 PLCs over ModbusTCP and they don’t support masked writes to registers.

The effect of this is that while Ignition can read bits from words, it cannot write to them. The workaround I’ve been using is located here: Troubles making a Derived Boolean Tag work as a mask for a Short Tag - #2 by Kevin.Herron

However, I’m seeing some strange behavior where the derived tags don’t work reliably in certain instances, failing with an unknown value ? symbol.

Specifically, I have 2 UDTs, one for Tank and one for Valve.
The Valve UDT has multiple BOOL derived tags defined, as well as their source WORD tags.
Instantiations of this UDT work fine on their own.
The Tank UDT has multiple BOOL derived tags AND multiple Valve UDT instantiations within.
Upon creating these tags or rebooting the gateway (possibly other times as well) the BOOL derived tags inside say tank1.valveA will fail. At this point, the log file fills up with the following on the gateway:

Error in derived tag
com.inductiveautomation.ignition.common.expressions.ExpressionException: Unsupported types for RShift: 'null' and 'java.lang.Long'
at com.inductiveautomation.ignition.common.expressions.BitwiseExpression.execute(BitwiseExpression.java:54)
at com.inductiveautomation.ignition.common.expressions.BitwiseExpression.execute(BitwiseExpression.java:42)
at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.reference.DerivedTagValueActorFactory$DerivedTagValueActor$Executor.execute(DerivedTagValueActorFactory.java:246)
at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.reference.DerivedTagValueActorFactory$DerivedTagValueActor.processIncomingValue(DerivedTagValueActorFactory.java:107)
at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.reference.TagReferenceValueActorFactory$TagReferenceValueActor.tagChanged(TagReferenceValueActorFactory.java:169)
at com.inductiveautomation.ignition.gateway.tags.subscriptions.ProviderSubscriptionManagerImpl$TagChangePublish.run(ProviderSubscriptionManagerImpl.java:1138)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

Right clicking on the UDT instance and restarting the tag allows the derived BOOL tags to work as expected.

I have a support ticket open, but it hasn’t been reproducible on their side. I thought I’d reach out here too.

Edit for screenshots of derived tag definitions:

1 Like

You’ll need to use coalesce({source}, 0) in your expressions to deal with transient nulls.

Where would there be transient nulls coming up?
Edit: Would coalesce({source}, 0) be required on both read and write expressions?

Update: After changing over all instances of {source} to coalesce({source},0) I’m still seeing issues with uncertain. See below:

An update: after upgrading to 8.0.11, it appears all bit derived tags that were previously working (albeit intermittently) now fail when writing with:

As I have scripts that write to multiple tags simultaneously, they all fail and the error log is flooded with:

This may need to go in another thread, but this appears to completely break boolean tags.

There seems to be a bug in the UDT parameter stuff right now that causes them to resolve as float/doubles, which in the case of these Modbus tags is turning the address from something that would be for a register, e.g. [Device]HR1 into something for a bit write, e.g. [Device]HR1.0.

This was supposed to be fixed in the 8.0.11 release but there’s apparently some case or cases that are still broken.

I think it’s the same thing as is happening in this post: [BUG]8.0.11-rc1 Numeric UDT parameters now appear as floats when used in OPC_Item_Path


I am attempting to figure out what went wrong with the upgrade in this case. Could you clarify how these UDT definitions were created? Were they created:

  • Within Ignition itself with the UI
  • Via a import file generated outside of Ignition
  • Via a import file generated within Ignition

The issue I am seeing is prior to 8.0.11, all numbers were considered Doubles or Strings depending on how they were created. If they were created within Ignition they were Strings, but if they were imported via JSON as numbers then they were considered Doubles.

On upgrade to 8.0.11, the Ignition created UDTs that have Strings are behaving as they were before in 8.0.10. Import created Doubles are being handled as Doubles now and having the .0 appended to the end of the value when it is evaluated as a parameter.


I had originally created them within the UI in Ignition and have done an export / import to modify the tag tree to include coalesce({source},0) in place of {source}

Does that answer your question?

Sorry I wasn’t more specific. The tag I am asking about is the definition of the OPC tag used for Source Tag Path.

Based on the errors we are seeing, it looks like the OPC Item Path is getting a .0 placed on the end of it because parameter is getting evaluated as a Double rather than an Integer.


The source tag path was included in the export import as stated above

It should have a OpcItemPath of


Modifying the instance of this OPC tag to do the arithmetic by replacing TagName with a literal 2 doesn’t fix anything.
The same is ALSO true if I replace Addr with 762.
This means that out of the 4 cases:


ONLY the last one with the literal arithmetic hard coded actually gives the right result in 8.0.11. This completely breaks most if not all of my UDTs.


The effort to remove the option to specify data types for UDT parameters seems unwise to me. /:

I did notice something was different! That was removed. Why??

The following syntax will allow for it to evaluate properly as it will force the result to be coerced into an integer:



Will this also fix the “error in derived tag” that are listed in the first post?

This will fix the OPC Item Paths not being correct after upgrade to 8.0.11, but likely won’t change the behavior you were seeing in 8.0.10.

If I were to try and troubleshoot the original issue, I would wrap the expression in a try and in the failover would (if scripting was available on the Gateway) call a script to log what condition is causing the error and work from there. At worst this gives you something to give to support to try and duplicate it in house.


In case it’s not clear to those following along, we definitely broke something with UDT params in 8.0.11.

We’re working on this right now and there’s going to be an 8.0.12 release with this fixed ASAP.

1 Like

An update on this. After upgrading to 8.0.12 the OPC parameter issue is gone, but I’m noticing a different behavior on the derived tags.

Now some of the tags that previously showed quality of uncertain and would error out when writing to them, now don’t indicate an error per sé.

A bool tag in the broken state that I’m seeing doesn’t have the black question mark in the tag browser, and in fact, shows up just like any other bool tag with the checkbox.

When I go to click on the checkbox, there is no error on write, but the checkbox never changes state.

The actual tag in the PLC does get set high when it is clicked. But since the checkbox doesn’t update, ignition never tries to write a 0 back on subsequent clicks. Viewing the tag status, I get uncertain quality.

Now since there are no errors, it’s harder to troubleshoot. Any ideas?

nothing coming up with {source} even though those tags have values that evaluate just fine…


anything else I can include in my script to make it more helpful?

Edit: as soon as I “restart tags” on the whole parent folder, everything works again.

To get back in a bad state, I disable and re-enable the realtime tag provider.

Any update on this? I’m still seeing the exact same behavior where {source} doesn’t appear to be having any value on tag provider start…