Values showing in Exponential Format
Dear sir
I am working with freelance 2016 sp1.One of my screen, the totaliser value crossed above 6 digits...(screen attached below).so my problem, As i created trend for above value.here actual value(1.03e+005), current value,SCS(-1.89e+0),SCE(8.02e+006) displayed in exponential format.So my question is why this exponential format coming & also how can change this exponential format to normal range like (96900.59,98879.56...etc).
Please help me someone to sort out this issue.
Thanks in Advance
I am working with freelance 2016 sp1.One of my screen, the totaliser value crossed above 6 digits...(screen attached below).so my problem, As i created trend for above value.here actual value(1.03e+005), current value,SCS(-1.89e+0),SCE(8.02e+006) displayed in exponential format.So my question is why this exponential format coming & also how can change this exponential format to normal range like (96900.59,98879.56...etc).
Please help me someone to sort out this issue.
Thanks in Advance
Asked 2 months ago
Answers
0
Hello John,
I guess the data type of the variables that you are trending is REAL. For REAL there is an automatic change in the representation for very high or very low numbers.
What you could do is to use variables of data type UDINT. You can convert your REAL variables to UDINT variables by using a converter function (TO_UD) before you connect the signals to your trend acquisition function block. You can continue to use the logic that creates your REAL variables for the counter values, but before you trend the signals convert them to UDINT.
After you place that function on your FBD (and before connecting it to the REAL variables) right click on the function and select "Change data type..." That will allow you to select the input data type that shall be converted to UDINT.
In the pop-up dialog press the right arrow button until the picture shows a REAL data type on the left side.
Then connect the input and route the output of this function to your trend acquisition function block.
I guess the data type of the variables that you are trending is REAL. For REAL there is an automatic change in the representation for very high or very low numbers.
What you could do is to use variables of data type UDINT. You can convert your REAL variables to UDINT variables by using a converter function (TO_UD) before you connect the signals to your trend acquisition function block. You can continue to use the logic that creates your REAL variables for the counter values, but before you trend the signals convert them to UDINT.
After you place that function on your FBD (and before connecting it to the REAL variables) right click on the function and select "Change data type..." That will allow you to select the input data type that shall be converted to UDINT.
In the pop-up dialog press the right arrow button until the picture shows a REAL data type on the left side.
Then connect the input and route the output of this function to your trend acquisition function block.
0
Hold the horses! I take everything back.
Even if you convert your REAL counter into an UDINT counter, the Trend display will show it in scientific notation once it goes over 99,999. It will then show the next value as 1.00e+005.
It does that independent of the data type of the variable. The problem with that is, that you do not see the next values from 100,001 to 100,999. Only 101,000 would show as 1.01e+005. Unfortunately there is no way around it in the current trend application. Don't get me wrong, internally all the values are counted, but you would not see a change in the "Actual" column until it increments over 1000.
What you could do, though it is a little awkward, is to split the counter value into 2 parts. One counting the 100,000 and the other showing the increments from 0..99,999. If you had a counter value of 366,432 it would appera as the value pair 3 and 66,432. Or you could show it as a value pair of 366 and 432. That would be more favorable if the value you count has a unit like liter. Then the first value shows the Kilo-Liters and the second value the liters since the last Kilo increment.
If you put both values into the trend. you could see the counter value. To do the split one would use the DIV and MOD functions.
Sorry for pointing you in the wrong direction first and having no better solution.
Even if you convert your REAL counter into an UDINT counter, the Trend display will show it in scientific notation once it goes over 99,999. It will then show the next value as 1.00e+005.
It does that independent of the data type of the variable. The problem with that is, that you do not see the next values from 100,001 to 100,999. Only 101,000 would show as 1.01e+005. Unfortunately there is no way around it in the current trend application. Don't get me wrong, internally all the values are counted, but you would not see a change in the "Actual" column until it increments over 1000.
What you could do, though it is a little awkward, is to split the counter value into 2 parts. One counting the 100,000 and the other showing the increments from 0..99,999. If you had a counter value of 366,432 it would appera as the value pair 3 and 66,432. Or you could show it as a value pair of 366 and 432. That would be more favorable if the value you count has a unit like liter. Then the first value shows the Kilo-Liters and the second value the liters since the last Kilo increment.
If you put both values into the trend. you could see the counter value. To do the split one would use the DIV and MOD functions.
Sorry for pointing you in the wrong direction first and having no better solution.
by JuergenV Rank: 71 on 4/10/2019 3:47:53 PM | Like (0) | Report
Hi!
would it help to have better precision (more digits shown) for the exponential format? I have seen a similar issue with alarm values/limits.
Are you aware that REAL is a single precision floating point value? You must ensure that the ratio between the increments and the absolute totalizer value is a good factor away from the 1.19e-7 relative precision of the REAL format, otherwise the totalizer value will not represent the sum of the increments as desired. It might make sense to use UDINT values to simulate fixed point arithmetics.
Best regards
Jürgen
Add new comment