Undocumented changes when migrating from v7 to v8

[nminchin]

Just some items I’ve found during v7 to v8 upgrades that may not be documented (some of them might be) and can cause hiccups (and quite a bit of work, relatively speaking!).
The official guide to upgrading from IA is here.
Tags:

• UDT v7 property UDTParentType has been renamed in v8 to TypeId
• Tag quality string values have changed. E.g. EDITED FOR 8.1.10 below 8.1.10 “Not Found” ==> “Bad_NotFound”; “Disabled” ==> “Bad_Disabled”; 8.1.10 and above “Bad_NotFound(Error description…)”, “Bad_ErrorConfiguration(Error description…)”. Also, integer values appear to have changed as well, such as if you were checking a tag’s quality value = 404 for not found; this no longer works.
• Tag properties have changed between versions:
  7.9.15____________________8.1
  
  Note: LastChanged was renamed to Timestamp, ScanClass to TagGroup
• You can no longer check the quality of a UDT instance (for example to check if it’s disabled); the quality always comes back as Good. For Disabled/Enabled, read the UDT instance property enabled instead.
• if you were using expression bindings in your alarm properties that reference alarm properties, you need to change all of these as these props are now properly dynamic as opposed to being pre-compiled (take them out of quotes) e.g. '{name} thing' become {name} + ' thing'
• UDT definition parameter data types are converted to Integer. If you were using Strings, for example, you’ll need to change these back to String. Need to confirm this is actually a thing
• Lots of UDT parameters get changed from String types into Integer types in the upgrade… While it doesn’t affect the current values from being correctly used proper, if you need to modify parameters later you get a warning and have to manually change these back to String.

Vision

• “Event Id” is added to the displayed headers of all Alarm Status Table components on existing Windows. Operators love to see this column (not )
• The default background colour has been changed from RGB(238,236,232) to RGB(250,250,251) . This affects existing Windows that use the default background colour for the Window and any containers as well.
• ‘Dialog’ font mapping has changed between versions. Original font was mapped to Lucida which is not licensed by the OpenJDK which 8 now uses, so this is now mapped to Google Noto Sans. The characters in this typeface are slightly wider than Lucida, so all Windows must be checked to make sure text still fits.
  Edit: I just noticed this option in the Gateway config
  
  
• Converted projects to 8 will have global Template templatePaths set to [shared]… however if you make changes to the template definition, these will not be reflected in these instances. You will need to change the template paths for all templates to use SharedTemplates/.... A find replace can do this easily. Edit: although there is a bug is some versions with find replace no longer finding things in unopened templates… Edit2: nope, this turned out to be a corrupted binding in one of my Templates. Once this was fixed, find/replace could find Templates again.
• the default button colour has changed from light grey to blue. Any buttons without a background set will change to blue
• if fonts are displaying pixelated, try added this option to the JVM arguments under the client launcher manage area: -Dawt.useSystemAAFontSettings=on. This usually doesn’t affect Windows, has a high chance of affecting Linux, not sure about Apple. (info courtesy of @Kevin.Herron)
• if you were using tag({Root Container.TagPrefix} + '/Infeed Screw/Running.Quality')='Disabled' to check quality in an expression, you’ll need to use this now: indexof(toStr(qualityOf(tag({Root Container.TagPrefix} + '/Infeed Screw/Running'))), 'Bad_Disabled') != -1

[nminchin]

Other cool things:

Perspective
Bindings:

1. You can bind to a tag group rather than a tag itself and it will basically represent as a json document with your tags in there. Very cool!
   Below, status is bound to a tag group (accidentally) which contains the tags Consumed Power, Call, etc. and these have each become properties with values that update with the tag values in realtime
   

[bkarabinchak.psi]

Just to add one to the list I ran into but [System]Client/System/CurrentDateTime did not used to have milliseconds in 7.9 but does in 8.1. Could be same for other System datetime tags.

How do I know? Project I inherited and am upgrading would grab and insert the value of this tag into a varchar(20) column that would work in 7.9 but in 8.1 the value was too wide. It's always funny what you find on the job lol

[pturmel]

It had milliseconds. Something in java probably changed the output format in your specific case.

[Kevin.Herron]

Phil’s correct, the underlying DataType has always been a Java Date, which has always had millisecond precision.

You were unwittingly relying on the “toString” behavior, a practice that is widely discouraged, and now have a personal anecdote as to why.

[bkarabinchak.psi]

You're both correct - the previous person did make a separate string vision client tag that references that tag. Makes sense now. The tag didn't change then, the toString method. Just another reason to use the the right datatypes on the DB and Ignition folks.

Still feel like this is worthy of this post though, not that it is the right way to do things, but I can't tell you how often I've consulted on projects and seen datetimes turned into strings and this change would certainly affect all of those if they upgrade.

[pturmel]

Meh. Blindly relying on .toString() for dates has always been chancy, particularly if localization gets involved. I'd say the upgrade did you a favor by exposing this time bomb.