After upgrading from 8.0.10 to 8.0.11-rc1 all OPC tags that use UDT numeric parameters fail with Config Error.
Example:
OPC_ItemPath = [{Driver_Name}]{Modbus_Address}.HRUI{Modbus_Offset+18452}
With following Parameters
Driver_Name = TapOff
Modbus_Address = 11
Modbus_Offse = 1
Used to return: [TapOff]11.HRUI18453
but now it returns: [TapOff]11.0.HRUI18453.0
It seems that all numeric parameters are now being cast as floats?
PS; 8.0.12 Nightly is the same
We’ll look into this right now.
@Kevin.Herron, I’m still in 8.0.10, but we make intensive use of this kind of modbus address computation. This issue will be fix in 8.0.11 ? and/or 8.0.12 nightly too ?
… bloody json number with no pure integer type
This is supposed to be fixed in the 8.0.11 release. It’s not part of the RC or 8.0.12 nightlies yet though.
Any update on when this one, it never made 8.0.11, also not in 8.0.12 as of today(2019-04-18)?
I’ve upgrade from Ignition 8.0.10 t o 8.0.11.
For existing tags the issue is still present because existing udt parameter have been converted for example “100,0”
If you create a new udt parameter with the value 100 then it’s ok.
No “,0” is added when you save.
I see 2 solution to fix upgraded application:
@mazeyrat, can you confirm that the OPC Item path is getting an Integer rather than a double? The reason I ask is there were changes in 8.0.11 where the Parameters don’t always show as Strings anymore in the Tag Browser. As the tag browser is converting them to a Double and it defaults to truncating any .0, the parameter itself does look like a 1. When it is used in an OPC path, it is still using 1.0 though (see screenshot below).
You can also check the datatype of the Parameter as well to ensure it is a Double. Let me know if this isn’t the case for you.
Garth
Yes, I suppose DataType was Double before I make the “fix”.
As my udts and tags are generated, I’ve deleted all of them and reimported all of them.
In the json file that I generate, integer parameter values have no .0.
These values create parameter with Integer type.
If your import file has 1 instead of 1.0 in it, then 8.0.11 will conclude it is an integer. As this is new due to changes for 8.0.11, is this the issue? The Parameters for my example above are the following when exported from 8.0.11:
"parameters": {
"Double1_1": 1.1,
"Double1_0": 1.0,
"Integer_2": 2
}
If you feel like you file is correct, can you please post an example (or PM one to me) so that we can look it over?
Thanks,
Garth
My file is correct and I have no more issue in 8.0.11 after deleting the udts/tags migrated from 8.0.10 and reimport those udts/tags.
So as for me, the issue is solved in 8.0.11.
But Parameters migrated to Double from 8.0.9 to 8.0.10 will stay Double in 8.0.11 and must be recreated in Integer…
Tested that here and yes, if I export the UDT definition and all the instances, drop the “.0” and import, those parameters are now all integers, also any newly created instances are integers too.
A couple of questions:
1 Will future Ignition versions say 8.0.12 allow me to upgrade without needing to do this?
2 This work round implies the parameters are stored with a data type, any reason why we cannot have the datatype drop-down like 7.9 to ensure no ambiguity?
Question 1: In looking at the definition in the pre-8.0.11 versions of Ignition, there isn’t going to be a way to understand the intent of the values. For the example I noted above, in 8.0.10 the parameters are stored as:
{ "name": "Example", "parameters": { "Double1_1": 1.1, "Double1_0": 1.0, "Integer_2": 2.0 }, "tagType": "UdtType" }
Notice there isn’t any real difference between the values of “Double1_0” and “Integer_2”. There isn’t a way to infer that the expected value was an Integer or a Double. We may be able to do something on upgrade, but there would be a risk of causing further damage.
Question 2: The goal was to get away from having to declare types for parameters in 8.0. When issues like this occur, we do review what changes might be needed to prevent this type of issue going forward.
Garth