# Upgrading Ignition **URL:** \ **Category:** Ignition\ **Created:** [July 2, 2012, 10:21am UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740 "2012-07-02T10:21:18Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [July 2, 2012, 10:21am UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/1 "2012-07-02T10:21:18Z")
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. ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [July 2, 2012, 10:48am UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/2 "2012-07-02T10:48:42Z")
Hey Al, The only thing I’ve seen on the forums specific to Jython has been about NaN and infinity: [topic here](http://inductiveautomation.com/forum/viewtopic.php?f=70&t=8214&p=26546&hilit=inf#p26546). ---
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [July 2, 2012, 11:06am UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/3 "2012-07-02T11:06:02Z")
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!). ---
**Author:** ![Michael.Stofan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.stofan/32/3342_2.png) [@Michael.Stofan](https://forum.inductiveautomation.com/u/Michael.Stofan)\ **Post date:** [July 2, 2012, 5:49pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/4 "2012-07-02T17:49:36Z")
Also, implicit importing of libraries is no longer supported. You can no longer do: ```auto import app.myPackage.* ``` You need to explicitly name your libraries to import: ```auto import app.myPackage.myFunction ``` or: ```auto 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. ---
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [July 2, 2012, 8:13pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/5 "2012-07-02T20:13:27Z")
Thanks Michael, I’m pretty sure this is one bad practice we have managed to avoid! ---
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [August 10, 2012, 4:27pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/6 "2012-08-10T16:27:57Z")
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 required`We 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 use`volume = "%.4f" % float(system.tag.read("[Client]Section 2/volume"))`but this gave the following error:`TypeError: float() argument must be a string or a number`The only way to get read to work was to use`volume = "%.4f" % float(system.tag.read("[Client]Section 2/volume").value)`even though the documentation for read says`If the tag path does not specify a tag property, then the Value property is assumed.`Anyone from Inductive Automation want to comment on this? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 10, 2012, 4:32pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/7 "2012-08-10T16:32:11Z")
> [@AlThePal](#): > > The only way to get read to work was to use`volume = "%.4f" % float(system.tag.read("[Client]Section 2/volume").value)`even though the documentation for read says`If the tag path does not specify a tag property, then the Value property is assumed.`Anyone from Inductive Automation want to comment on this? system.tag.read() returns a QualifiedValue object, which you can retrieve the value, quality, or timestamp from. ---
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [August 10, 2012, 4:37pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/8 "2012-08-10T16:37:39Z")
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. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 10, 2012, 4:50pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/9 "2012-08-10T16:50:40Z")
> [@AlThePal](#): > > 1. Is it correct that getReadValue's behaviour has changed, necessitating the use of float when that was not necessary in version 7.2? 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. > [@AlThePal](#): > > 1. The documentation for read states that if no property is specified value is assumed. This is not happening. 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). ---
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [August 10, 2012, 4:56pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/10 "2012-08-10T16:56:29Z")
[quote]Assuming you meant getTagValue here[/quote] Indeed! 😆 Thanks for clearing up those points Kevin. If anyone is upgrading it will be worth them looking at their use of string formatting. ---
**Author:** ![Step7](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@Step7](https://forum.inductiveautomation.com/u/Step7)\ **Post date:** [August 10, 2012, 6:16pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/11 "2012-08-10T18:16:03Z")
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? ```auto 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()? ---
**Author:** ![Michael.Stofan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.stofan/32/3342_2.png) [@Michael.Stofan](https://forum.inductiveautomation.com/u/Michael.Stofan)\ **Post date:** [August 10, 2012, 9:26pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/12 "2012-08-10T21:26:05Z")
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. ---
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [August 10, 2012, 9:56pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/13 "2012-08-10T21:56:10Z")
Hi Step7, I’m not actually dividing by volume - the ‘/volume’ is part of the client SQLTag name 😉 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. ---
**Author:** ![Carl.Gould](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/carl.gould/32/7262_2.png) [@Carl.Gould](https://forum.inductiveautomation.com/u/Carl.Gould)\ **Post date:** [August 10, 2012, 10:04pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/14 "2012-08-10T22:04:10Z")
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. ---
**Author:** ![Step7](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@Step7](https://forum.inductiveautomation.com/u/Step7)\ **Post date:** [August 10, 2012, 10:07pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/15 "2012-08-10T22:07:33Z")
[quote=“AlThePal”]Hi Step7, I’m not actually dividing by volume - the ‘/volume’ is part of the client SQLTag name 😉[/quote] Thanks Al, that makes sense. I don’t use sql tags, so I didn’t catch that at all. 🙂 I think I’ll be fine. ---
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [August 10, 2012, 10:15pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/16 "2012-08-10T22:15:34Z")
Hi Carl, Both type(system.tag.read().value) and type(system.tag.getTagValue()) return`` ---
**Author:** ![James.Lorenz](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/james.lorenz/32/3290_2.png) [@James.Lorenz](https://forum.inductiveautomation.com/u/James.Lorenz)\ **Post date:** [August 10, 2012, 10:27pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/17 "2012-08-10T22:27:55Z")
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)? ---
**Author:** ![AlThePal](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/althepal/32/3603_2.png) [@AlThePal](https://forum.inductiveautomation.com/u/AlThePal)\ **Post date:** [August 11, 2012, 1:46pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/18 "2012-08-11T13:46:54Z")
Hi James, We are using the stable release 7.5.1.1122 - and you are quite correct ![:thumb_left:](https://us1.discourse-cdn.com/inductiveautomation/original/1X/e26afb081ddde6df016df6ee49159cf56aaca688.gif ":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 like`volume = "%.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 either`volume = "%.4f" % float(system.tag.getTagValue("[Client]Section 2/volume"))`or`volume = "%.4f" % float(system.tag.read("[Client]Section 2/volume").value)` Something to watch out for on upgrading! ---
**Author:** ![Carl.Gould](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/carl.gould/32/7262_2.png) [@Carl.Gould](https://forum.inductiveautomation.com/u/Carl.Gould)\ **Post date:** [August 13, 2012, 4:44pm UTC](https://forum.inductiveautomation.com/t/upgrading-ignition/4740/19 "2012-08-13T16:44:41Z")
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.