# \[Bug - 16356\]Derived Tags for Bit usage **URL:** \ **Category:** Ignition\ **Tags:** ignition80\ **Created:** [April 17, 2020, 1:30pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007 "2020-04-17T13:30:06Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 17, 2020, 1:30pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/1 "2020-04-17T13:30:06Z")
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](http://forum.inductiveautomation.com/t/troubles-making-a-derived-boolean-tag-work-as-a-mask-for-a-short-tag/15203/2) 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: ```auto 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: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/2/263a7c373620310eca59de1f7f296080d28db6e6.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/9/965f18e476e96200885feec3eac072caba158c2c.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/a/a223975cdfd0620f88e882df3279805272042eb2.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/0/0820b7e3d69697cc2abf5e83a4f710927cbe6653.png) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 17, 2020, 2:02pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/2 "2020-04-17T14:02:48Z")
You’ll need to use `coalesce({source}, 0)` in your expressions to deal with transient nulls. ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 17, 2020, 2:22pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/3 "2020-04-17T14:22:28Z")
Where would there be transient nulls coming up? Edit: Would `coalesce({source}, 0)` be required on both read and write expressions? ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 17, 2020, 2:50pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/4 "2020-04-17T14:50:19Z")
Update: After changing over all instances of `{source}` to `coalesce({source},0)` I’m still seeing issues with uncertain. See below: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/3/3bce86b8a8981e4a11cad54635570abb298ed6b3.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/8/8d85709d32a3a289ecbf31c199de26476951e89e.png) ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 20, 2020, 2:17pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/5 "2020-04-20T14:17:53Z")
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: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/c/c187860e5d697ff9044f6d3eec18b5252fc99f69.png) As I have scripts that write to multiple tags simultaneously, they all fail and the error log is flooded with: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/e/e6fc9357b1e45dff821969d570360069f4e81baa.png) This may need to go in another thread, but this appears to completely break boolean tags. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 20, 2020, 2:25pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/6 "2020-04-20T14:25:17Z")
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](http://forum.inductiveautomation.com/t/bug-8-0-11-rc1-numeric-udt-parameters-now-appear-as-floats-when-used-in-opc-item-path/33600/5) ---
**Author:** ![ggross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ggross/32/12668_2.png) [@ggross](https://forum.inductiveautomation.com/u/ggross)\ **Post date:** [April 20, 2020, 4:57pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/7 "2020-04-20T16:57:52Z")
@cbiela, 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. Thanks, Garth ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 20, 2020, 9:15pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/8 "2020-04-20T21:15:04Z")
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? ---
**Author:** ![ggross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ggross/32/12668_2.png) [@ggross](https://forum.inductiveautomation.com/u/ggross)\ **Post date:** [April 20, 2020, 9:37pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/9 "2020-04-20T21:37:50Z")
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. Thanks, Garth ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 20, 2020, 11:46pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/10 "2020-04-20T23:46:43Z")
The source tag path was included in the export import as stated above ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 21, 2020, 12:11pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/11 "2020-04-21T12:11:09Z")
![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/7/78633d7b12a1e92d4c8f77a6d7f4de2355699ebc.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/1/10df9165c73a1b9750ebb5b4e80dcea7585cff2a.png) It should have a `OpcItemPath` of ```auto ns=1;s=[myplc]HRUS764 ``` 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: ```auto ns=1;s=[{PLC_NAME}]HRUS{Addr+TagName} ns=1;s=[{PLC_NAME}]HRUS{Addr+2} ns=1;s=[{PLC_NAME}]HRUS{762+TagName} ns=1;s=[{PLC_NAME}]HRUS{762+2} ``` 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. [https://docs.inductiveautomation.com/display/DOC80/UDT+Definitions#UDTDefinitions-AttributeReferencingandParameterizedTypes](https://docs.inductiveautomation.com/display/DOC80/UDT+Definitions#UDTDefinitions-AttributeReferencingandParameterizedTypes) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 21, 2020, 12:17pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/12 "2020-04-21T12:17:28Z")
The effort to remove the option to specify data types for UDT parameters seems unwise to me. /: ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 21, 2020, 12:24pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/13 "2020-04-21T12:24:29Z")
I did notice something was different! That was removed. Why?? ---
**Author:** ![ggross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ggross/32/12668_2.png) [@ggross](https://forum.inductiveautomation.com/u/ggross)\ **Post date:** [April 21, 2020, 2:30pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/14 "2020-04-21T14:30:21Z")
The following syntax will allow for it to evaluate properly as it will force the result to be coerced into an integer: ```auto ns=1;s=[{PLC_NAME}]HRUS{Addr+TagName|#} ``` Garth ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [April 21, 2020, 3:16pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/15 "2020-04-21T15:16:14Z")
Will this also fix the “error in derived tag” that are listed in the first post? ---
**Author:** ![ggross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ggross/32/12668_2.png) [@ggross](https://forum.inductiveautomation.com/u/ggross)\ **Post date:** [April 21, 2020, 4:14pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/16 "2020-04-21T16:14:12Z")
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. Garth ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 21, 2020, 6:29pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/17 "2020-04-21T18:29:34Z")
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. ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [May 2, 2020, 11:31am UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/18 "2020-05-02T11:31:33Z")
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? ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [May 2, 2020, 1:58pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/19 "2020-05-02T13:58:55Z")
![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/b/b97bc1ea52041b2bb41eadee9a7fc57ed230f885.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/4/4447b772cfb02586347e825274bf5585325d0eac.png) nothing coming up with `{source}` even though those tags have values that evaluate just fine… ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/b/b30521b70f4e14e65b1fac62679cd14b30123a25.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/3/372cb550f6dbaea5875ea6d47ab0f95a0cf28adc.png) 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. ---
**Author:** ![cbiela](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cbiela](https://forum.inductiveautomation.com/u/cbiela)\ **Post date:** [June 8, 2020, 5:50pm UTC](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007/20 "2020-06-08T17:50:24Z")
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… [Next page](https://forum.inductiveautomation.com/t/bug-16356-derived-tags-for-bit-usage/34007.md?page=2)