Upgrading Ignition

Ignition
1

Has anyone had experience of upgrading Ignition from the 7.2 branch to 7.3+, specifically with regard to the upgrade to Jython 7.5?

We have a large system installed with 7.2 that includes loads of Jython code and I was wondering what has changed that we will have to look out for.

2

Hey Al,

The only thing I’ve seen on the forums specific to Jython has been about NaN and infinity: topic here.

3

Thanks Jordan. We don’t use either Nan or Infinity so hopefully will be OK. Doing this upgrade is exposing one of Ignitions biggest weaknesses - the difficulty of testing embedded code. At the moment we are trialling testing at the user interface level using QFTest (which Inductive use internally) and it seems ideal (although expensive!).

4

Also, implicit importing of libraries is no longer supported. You can no longer do:

import app.myPackage.*

You need to explicitly name your libraries to import:

import app.myPackage.myFunction

or:

from app.myPackage import myFunction

This is one of those things that probably shouldn’t have worked in the first place, as it’s considered bad practice.

5

Thanks Michael, I’m pretty sure this is one bad practice we have managed to avoid!

6

We upgraded Ignition from 7.2.7 to 7.5.1 and it seemed to go very smoothly. We’re now doing lots of testing and have come up with the following issue:

We used to read client tags in as a float using code like:volume = "%.4f" % system.tag.getTagValue("[Client]Section 2/volume")However trying to run this code now gives us the following error:TypeError: float argument requiredWe can sort this problem by changing the code to the following:volume = "%.4f" % float(system.tag.getTagValue("[Client]Section 2/volume"))As the getTagValue call has been replaced by read, we tried to usevolume = "%.4f" % float(system.tag.read("[Client]Section 2/volume"))but this gave the following error:TypeError: float() argument must be a string or a numberThe only way to get read to work was to usevolume = "%.4f" % float(system.tag.read("[Client]Section 2/volume").value)even though the documentation for read saysIf the tag path does not specify a tag property, then the Value property is assumed.Anyone from Inductive Automation want to comment on this?

7

system.tag.read() returns a QualifiedValue object, which you can retrieve the value, quality, or timestamp from.

8

Yes, but

  1. Is it correct that getReadValue’s behaviour has changed, necessitating the use of float when that was not necessary in version 7.2?

  2. The documentation for read states that if no property is specified value is assumed. This is not happening.

9

Assuming you meant getTagValue here, but my guess would be that the behavior of Python's string formatting changed. The code implementing getTagValue looks the same between versions.

You're misinterpreting the docs. It's referring to the Value property of the SQLTag (as opposed to the other tag props, name, quality, enabled, deadband, tooltip, etc...), not the value property of the QualifiedValue. The result of this call is always a QualifiedValue for the requested tag prop (default is Value).

10

[quote]Assuming you meant getTagValue here[/quote] Indeed! :laughing:

Thanks for clearing up those points Kevin. If anyone is upgrading it will be worth them looking at their use of string formatting.

11

Hmm, I was thinking of upgrading from 7.28, but I do a lot of string formatting. Is it only floats that might be a problem?

I grabbed a snippet of code from one of my screens where I do some float formatting, but I divide the formatted value by 10.0, so I’m guessing it would be correctly interpreted as a float without the explicit float(…). Can someone tell me if this will be a problem?

stats="%d / %d / %.1f%%"%(i['Min'],i['Max'],i['Average']/10.0)

And Al, in your code above, you are dividing by ‘volume’. If you had explicitly defined it as a float where it is instantiated, would your code have worked without adding float()?

12

Your best bet to make sure your project works in newer versions of Ignition is to install Ignition 7.5.x on a separate machine (spare laptop or desktop) and import your 7.2.8 gateway backup. Otherwise it’s hard to tell if you’ll have problems with string formatting just by looking at it.

13

Hi Step7,

I’m not actually dividing by volume - the ‘/volume’ is part of the client SQLTag name :wink:

Using string formatting works fine when calculating values, either integer or float. The problem comes when using the system.tag.read call.

When I tried dividing the value returned by the call by a float the following error appeared:TypeError: unsupported operand type(s) for /: 'unicode' and 'float'Apparently the system.tag.read(tagname).value call and the system.tag.getTagValue(tagname) call are both returning a Unicode string.

This behaviour seems to have changed since version 7.2. If this is the case, it would seem better to me that the read call returns (or provision is made to return) an appropriate data type.

14

Just to be clear: the behavior of getTagValue has not changed. I wonder what type it is returning if not a float? You could find out by investigating it using the [tt]type()[/tt] function.

15

[quote=“AlThePal”]Hi Step7,

I’m not actually dividing by volume - the ‘/volume’ is part of the client SQLTag name :wink:[/quote]

Thanks Al, that makes sense. I don’t use sql tags, so I didn’t catch that at all. :slight_smile: I think I’ll be fine.

16

Hi Carl,

Both type(system.tag.read().value) and type(system.tag.getTagValue()) return<type 'unicode'>

17

The type should only return “unicode” if the tag that system.tag.read is reading is a string. Are you sure the tag you used for testing that type return isn’t a string?

Also, you said you’re using 7.5.1, is that the stable release (7.5.1.1122)?

18

Hi James,

We are using the stable release 7.5.1.1122 - and you are quite correct :thumb_left: Despite holding a numeric value the SQLTag is actually a string. The reason for this is the value is optional - it is stored in the relational database as either a number (if set) or null (if not set). The only way we could find to store this in a SQLTag was as a string containing a number (if set) or blank (if not set). This wasn’t possible if we used a float.

Obviously string formatting has changed between Jython 2.1 and 2.5. A line likevolume = "%.4f" % system.tag.getTagValue("[Client]Section 2/volume")used to work perfectly in Ignition v7.2 - the string formatting must have been implicitly converting from a string to a float. You now have to use eithervolume = "%.4f" % float(system.tag.getTagValue("[Client]Section 2/volume"))orvolume = "%.4f" % float(system.tag.read("[Client]Section 2/volume").value)
Something to watch out for on upgrading!

19

Ah, the tag was a string! Yeah, I guess Python got more strict when it came to string formatting between 2.1 and 2.5. Thanks for the conclusion.