[Bug Report] Curly brackets (braces) on commented line in udt instance script causes script to fail silently

Including open/close curly brackets (braces) with any text in between, on a commented line (e.g. #{z}), in a value changed value event script, on a tag in a udt definition... causes the script to fail silently on UDT instances showing no errors in the script editor and no errors in the logs.

Any of these lines causes silent failure of the script with no lines executed.
# here is an innocuous comment that should not affect anything but {does}

I tested for the same on atomic tags not in a udt definition/instance and that does not appear to have the same issue.

I suspect this relates to the fact that there are a few valid parameters that can be use inside a UDT definition/instance so a pre-processor might be attempting map anything bounded by curly brackets as a parameter reference. I suspect the same silent error mode might occur for any text bounded by braces that is not a valid parameter reference; commented line or not (untested).

Suggested resolutions for Ignition developers to consider:

  1. Do not evaluate comment lines/text for parameter references.
  2. In the event of an invalid parameter reference provide suitable errors in the logs instead of failing silently.

I ran into this while building a udt definition to pull data from api.weather.gov. I copied some text from the general-faqs page as script comments...

# Retrieve the metadata for your location from https://api.weather.gov/points/{lat},{lon}.
# For our example the URL will be https://api.weather.gov/points/38.8894,-77.0352

...and my scripts started to fail silently, it took some time (line by line elimination) to understand why. I was not expecting a commented out line to impact the script execution like this.

Posting here in an effort to save others the same head scratching and hopefully improve the product by prompting a bug fix.

Ignition v8.1.31


Here is JSON for a UDT definition I created to test/confirm my findings.

  "name": "test udt definition",
  "tagType": "UdtType",
  "tags": [
      "valueSource": "expr",
      "eventScripts": [
          "eventid": "valueChanged",
          "script": "\tprint tagPath, currentValue\n\t# here is an innocuous comment that does not affect anything \n\t# here is an innocuous comment that should not affect anything but {does}"
      "expression": "now(5000)",
      "dataType": "DateTime",
      "name": "test tag with value changed script",
      "formatString": "yyyy-MM-dd h:mm:ss aa",
      "tagType": "AtomicTag"

Might be worth to contact support directly as well on this to close the loop on bug reporting.

1 Like

Thanks. I've had decent luck with Ignition developers responding to bug reports on the forum and converting then to internal tickets. If there is a more formal/proper way to submit a bug report, that is other than talking to someone on the phone, I'd be happy use it.

I now know what to avoid so my post was meant for the benefit of others, or for future me who has since forgotten.

The only formal way to submit a bug report is via support. You can open web and email tickets with support in addition to calling.

@Kevin.Herron do you advise/request that I do that (open web and email tickets with support) or does your team pro-actively respond to bug reports on the forum also? The advantage to me of having it on the forum is that I can find the info again when I am having the same problem (others can too).

I'll open a ticket this time, but in general, if you want a formal way to submit a bug report that won't get missed or ignored on occasion, use support.


Thanks! I suppose the nice thing about submitting a support ticket myself is that I might have better visibility on when a reported bug is acknowledged and then addressed/resolved. I'm convinced.

Yes, you can ask them to notify you when it's fixed as well.

This forum post is linked in the ticket I created, but it's not a sure thing that somebody will come back and update it.