[QUESTION] INT64 type in opcua returns this...

[henjoe]

I wonder if this is normal, on my opcua server I have Int64 type and currently have value = 14,084

Now looking at my Fuxa it seems it reads different, the value I am receiving is something like this value = 0,14064

I don't know where it gets that 0, before the real value of 14064, but basically this is something wrong right?

Thanks.

[henjoe]

Changing the dataType to Int32 from my OPCUA server now I am getting the exact value. But fuxa should work both from int32 and Int64. If this is something BUG please let me know.

Thank you.

[unocelli]

Hi, the Int64 will be converted to an array of 2 elements (Int32), for Int64 in Javascript we should integrate BigInt

[henjoe]

Hi @unocelli thanka for confirmation.

You mean do I need to apply scaleRead convertion in order to fix this?

[MatthewReed303]

@unocelli this should be fixed in Fuxa to always display int64 value as a whole. I have also been having trouble with this with the TIME data type being an INT64 also, I mucked around with the scale to try and convert the array to a whole but did not get it working correctly. I guess this is because I probable need the BigInt you mention

[unocelli]

@MatthewReed303 I would like to understand why you have to have an Int64 for TIME?

[MatthewReed303]

@unocelli because the underlying datatype coming from the OPC-UA server are standard INT datatypes representing the time in ms, the issue is Fuxa displays the TIME datatype as 64bit same with DATE etc which is then represented as an array like above

This should be displayed as a whole number. I am using a script to covert it and grab one section of the array, but if the number is larger than 32 bit it fails. As you can see I have 2500ms which is not an issue, but if I go larger than 32bit it's an issue, using the LTIME/LDATE/LTOD etc I don't know why node opc is displaying the 32bit datatypes as 64bit, maybe that's something to look into? But I do know UaExpert also displayed them as int64 but returns the correct value as whole.

on the read script I just return the position of the array

return value[1];

on the write script i just return the whole value

return value;

We should not have to apply any scripting to get the raw 64bit value. To see more on TIME/LTIME/DATE datatypes see below

https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_datatype_time.html https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_datatype_date_and_time_of_day.html

[henjoe]

Yep. The point here is it will always be better to get raw value from the INT64 OPCUA tag without applying any script. Which most of opcua client has this capability. I hope fuxa has this too.

[unocelli]

@MatthewReed303 My question was more to understand why you use 64Bit to describe TIME, when 32Bit is sufficient.

[MatthewReed303]

@unocelli because it comes from OPC as a 64bit and it should be a whole number, we should not have to use scripts to convert it. Also I'm working on a project that will be using LDT ( long date time as we need ms resolution and DT is only seconds ) the LDT is 64bit. Fuxa should handle 64bit datatypes correctly since it is becoming a lot more common in PLCs etc