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.
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 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}
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.
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:
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.
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?
