[IGN-8411] Curly brackets (braces) on commented line in udt instance script causes script to fail silently

Ignition
,
1

Including open/close curly brackets (braces) with any text in between, on a commented line (e.g. #{z}), in a value changed event script, on a tag in a udt definition... causes the script to fail silently 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.
#{L}
# 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
@PGriffith
@Kevin.Herron

4 Likes
2

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"
    }
  ]
}
3

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

1 Like
4

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.

5

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.

6

@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).

7

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.

2 Likes
8

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.

9

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.

10

I confirmed that this is still an issue in v8.1.35.

11

This parameter resolution behavior also wreaks havoc when one attempts to use string formatting with keyword arguments such as

'{x}/{y}/{z}'.format(y='bar', z='baz', x='foo')

(A Guide to the Newer Python String Format Techniques – Real Python)

12

I'll add this information to the ticket, it's more compelling than just comments being affected.

The owners are (rightfully) scared to mess around with this code for fear of breaking something and so they prioritized it low and have been ignoring it.

14

@Kevin.Herron, any updates on resolution for this bug?

Looks to be an issue others are still bumping into.

Even failing with an informative error in the log would be better than failing silently.

Also, I reported a bug where a commented-out line containing a parameter reference in a named query causes the query execution fail. Perhaps not directly related but similar, maybe due to similar practice/implementation in resolving parameter references without consideration of lines that are commented out.

15

If you make all of your event scripts one-liners delegating to project library script functions (like you should), this problem disappears.

/me runs away :laughing:

4 Likes
16

I have not been working in Ignition that long, why is this recommended? Simply to avoid issues like this?

17

Access to long-lived variables and constants, including imports and loggers.

Access to reliable python module global variable behavior.

Maintainable place to find all of your non-trivial scripts.

1 Like
18

I'm always interested in hearing perspectives on best-practice. Thanks!

However, I tend to want my UDT definitions (and tag configurations) to be self-contained (and portable) as far as is possible, and I tend to avoid external dependencies unless using external dependencies (like the project script library) would provide actual functionality, maintainability or reusability benefit. A hard argument to make for tag event scripts that have no purpose other than for a specific UDT/tag.

Perhaps it is a valid work-around, but in the context of a bug report your comment feels like saying there is another bathroom (and I think it's better), so one should not worry about maintaining the other (broken) bathroom that people see first and naturally try to use.

I also have an interest in just helping to improve the product by reporting and following up on bugs that I find through real use (big or little). I've found quite a few, and my feature wish-list is growing, but I still have a great appreciation for Ignition.

1 Like
19

Certainly valid. Which is why I appended the snarky suffix.

20

@Pturmel, my mini rant was a result of my mental exercise trying to get onboard with your generalized assertion of best practice when applied to some of my specific use cases and perhaps just a little response to perceived belittling of my efforts to track a bug to resolution.
Snarky suffix noted and appreciated. :grinning: