Python String Formatting in Tag Change Script

Ignition
, ,
1

It seems like pythonic string formatting is broken within tag-change event scripts.

For example, writing

value = currentValue.value
ack_value = "{0}_ACK".format(str(value)) # unnecessary str() call, but used for comparison only

does not work, but

value = currentValue.value
ack_value = str(value) + "_ACK"

does. We get no errors on the gateway and cannot run any code above or below the str().format() call until it is removed. Is the Jython environment within the tag-change script a different version or using different imports from the environment found on the gateway or in perspective? I would at least expect an error of some kind to trigger telling me it doesn't like the library or why none of the rest of my code runs. No other external library is being called aside from this.

Even if this line is the final line in 1000+ python lines, and there are dozens of loggers, it still produces no output or errors or even warnings in the gateway logs until I remove that string formatter. I don't know if other python calls on tag-change scripts also cause this issue. Anyone else run into this issue or similar?

Also, this is version 8.1.17 for reference.

Cheers,
Roger

2

This is almost certainly happening because the {} are being parsed as a parameter reference before the actual string gets evaluated as code. I don't know offhand if there's a way to escape, but you could always use legacy string formatting ("%s" % (args)), or, better, call out to a project library script from your tag script.

2 Likes
3

I didn't even consider that, but you're right, curly braces are used for UDT parameter references aren't they? So essentially it is looking for a parameter reference of some parameter named 0 in this case which it would fail to locate. Interesting.

If there is a way to escape those characters, that would be cool. I do think some kind of error message about this as a hint would be nice, or something detailing that the curly-braces in python in a tag-change script could pose issues. I would have never known!

As you said, we can just call out to our project library script from the tag script, that would work. Much thanks!