Creating EURange, EngineeringUnit and Subunit Sub-tag

Ignition Modules MQTT Modules
1

Hi all,
I am creating tags with the source from OPC-UA server using Gateway script ( system.tag.addTag). The tags will then publish to AWS IoT Core via MQTT. I have noticed the three tags: EURange, EngineeringUnit and Subunit failed to create with the following error: Bad_Unsupported(“The target path ‘[TAG Provider]Motor/Shaft/Keyphaser Channel/Speed’ cannot accept children tags.”).

When browsing it using the Tag Browser within the Designer I can see the 3 tags are sub-tag under the Speed tag.

image

I am aware of the “solution” mentioned [BUG-12935] Import tags - Ignition Early Access - Inductive Automation Forum. The three tags created at the 1 level up with out issue, i.e. [TAG Provider]Motor/Shaft/Keyphaser Channel. However, this doesn’t reflect on how the tag structure from the source, and I am afraid this may create conflicts in the wrong run as the 3 tags may exist at the other tags in the same level, e.g. [TAG Provider]Motor/Shaft/Keyphaser Channel/Speed2.

Can you please advise if there is any solution for me to create the three tags and preserved the folder structure? i.e. creating the sub-tag? Alternately, I have noticed the tag Numeric properties consists of the Engineering Unit, Engineering Low and High Limit. Is there anyway I can script to update those attributes and includes the attribute to the MQTT payload to AWS?
image

Thank you in advance.

2

Are UDTs or using tag properties a potential solution for you? As far as I know you can’t have tags under regular tags.

3

I have started to test out my script to update the properties of the tag today. Haven’t quite gotten it to work yet. From my understanding, the Properties will be advertised to the MQTT broker as part of the DBIRTH and DDATA messages (if the value of the properties changes?) along with the value of the standard tag. Is this assumption correct?

4

I have since confirmed both the custom properties and the build-in properties are included in the MQTT payload and should serve the purpose of publishing the three mentioned values to AWS. I am happy with this outcome.

Thanks again.

5

Great. I should note that property changes are not reflected in DATA messages. Properties only come across in BIRTH messages.