In 7.9 this binding:
{sitePath}{area}{parent}{InstanceName}.ActiveRecipeName
evaluated to:
[global]\Harman\Szekesfehervar\Microphones\HFM14\PLC.ActiveRecipeName
In 8.0.1 the same binding evaluates to:
[global]\Harman\Szekesfehervar\Microphones\HFM14\HFM14.ActiveRecipeName
This occurs in a complex data type, where the PLC instance exists as an element of HFM14.
Screenshots:
7.9.10
8.0.1
Thanks for reporting, I’ve made a bug ticket to track this.
@Kevin.Herron thanks. So to be clear, the intention is for the behavior of InstanceName to remain the same as before. Correct?
There are only a few things we intentionally broke backwards compatibility on. In most cases any project upgraded from 7.9 should continue to work on 8.0 without modifications.
So, yes, we’ll fix this so it acts like it did in 7.9.
This issue was fixed in the 8.0.2 nightly build that was uploaded today (5/17).
I just installed 8.0.3 nightly, and are still seeing misbehavior regarding InstanceName.
I have an alarm configuration like this:
“’{InstanceName}’ + ’ - ’ + {[.]…/Description} + ’ høy alarm’”
The alarm tekst is then printing “{InstanceName} - høy alarm”
Is there no good equivalent to the instanceName ?
Been looking trough Expression - Alarm proprieties - Main, but can’t find any UDT name.
Which alarm property are you trying to use the InstanceName parameter reference? The ones I tested were working as expected.
Kevin, Is there a difference between an install and its projects being “upgraded” or simply importing projects from 7.9 to 8? Is it safe to presume that projects when imported to a clean 8 install will be “upgraded” ?
Imported projects get converted as well, but it’s a different code path and conversion routine than an upgrade, so let us know if you see anything weird.
Not project but we also imported UDTs from 7.9 so in regards to " 13801: UDT definition was not importing correctly when the provider root folder was selected " Does this mean UDTs from 7.9 should be re-imported to fix the “default” scan class issue where tags just start writing history random despite the fact they had no history enabled? Or can one assume that with 8.0.2 upgrade these issues get resolved during the upgrade?
Just restored our 7.9 gateway to 8.0.2. b2019060511 and the bug is still present.
A fix was merged and released with 8.0.2 so I’m not sure if you’re seeing a different issue or if QA tested something different or what.
Are you still seeing this on the example from your first post?
@Kevin.Herron ok, I figured it out. It’s a different case than the original one.
Firstly, in trying to fix this, I upgraded to 8.0.3 RC2. The following is from this version. But I guess the fix below would have worked in 8.0.2.
In this case we have a parameter that is using a reference. See below. This Data Type was imported from 7.9.
the parameter is used in a tag inside the structure.
And does not get resolved.
I fixed it by modifying the parameter value to something else, committing the change, and then changing it back to the original value. Once this is done, the tag resolves correctly.
Note the import of the 7.9 tags occurred when Ignition was at 8.00, or something prior to 8.0.2. So a 7.9 import into 8.0.2 might not exhibit this error.
I re-imported the 7.9 tags into 8.0.3 rc2, and everything looks good.
