Hi,
I would like to disable a double parameter under certain circumstances. I would like to do this by setting the value to be the maximum allowed value for a double (all other values are valid values). Could you please let me know how to represent this in the XML file? i.e. what do I put in the xxx below? Thanks
<Interprete>
<Type>double</Type>
<RawType>double</RawType>
<LengthType>fixed</LengthType>
<Length>8</Length>
<Exceptions>
<Exception id="1" value="xxx">
<Display state="disabled">NOT INITIALIZED</Display>
<Value>xxx</Value>
</Exception>
</Exceptions>
</Interprete>
Hi,
When increasing the loglevel of the element when trying to set that value (Double.MaxValue), it can be seen from SLProtocol that this raw value is 0xFFFFFFFFFF FFEF7F (which matches the specs for a double that uses mantissa and exponent in the background). This is then converted into a VT_R8 which is the value that SLElement gets. When trying that value then it works for me. I tried the shorter 0x variant both with little and big endian without success.
The only thing that worked in my case when performing a protocol.SetParameter from a QAction with value Double.MaxValue was by specifying that VT_R8 number that I found when increasing the loglevel. I don't know if any rounding issues could occur but it's worth to try with below example.
Like João mentioned in his answer, we usually try to find a logical limit in the parameter to avoid having to rely on such large numbers. I seems strange that eg a Double.MaxValue - 1 would still be considered as a valid number, that one can't even be fully displayed on the element card, so there has to be a more logical high limit to the parameter that is being displayed in the UI.
<Interprete>
<RawType>double</RawType>
<LengthType>fixed</LengthType>
<Type>double</Type>
<Length>8</Length>
<Exceptions>
<Exception id="1" value="179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368">
<Display state="disabled">NOT INITIALIZED</Display>
<Value>179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368</Value>
</Exception>
</Exceptions>
</Interprete>
Adding some more info why that value works. In the background there are different types of program languages being used. A maximum double is (in big endian) equal to 0x7FEFFFFFFFFFFFFF in memory, these are the bytes that are being exchanged between the different processes and these bytes are according to IEEE 64-bit (8-byte) floating-point. It’s writing out the value as a number that is different between programming languages. The SLScripting QAction (usually) has C#, a maximum double is represented as 179769313486232 followed by 294 zeros. That is what João tried as solution to fill as value. Several server side processes, like SLProtocol, use C++ in the background, a maximum double there is represented as the large number that was written out like in my answer. It’s in such a kind of process where the comparison happens to check if the incoming value is equal to the value defined in the exception, so the C++ max value needs to be defined in the xml tag to have a match. Client side uses a different programming language and displays the value again like C# does. In other words, the exception value is depending on the way the used programming language displays it. If the developers of C++ ever decide to change the way a maximum double is displayed as a number and make it the same like C# then the driver will be broken. Similar if the developers of the DataMiner software ever decide to change to a different type of process in the background then the driver will also be broken. In my personal opinion I would not use such an extreme number as an exception value, there should be a more realistic number that is lower that can be used and won’t cause problems between different programming languages