I have found a bug in pv 2.7.
When I modify the Visibility condition min and max range, using a decimal point, the entered range is not stored correctly.
Somehow it does not accept this decimal point.
Whole numbers work ok.
The condition is a J1939 variable with a resolution of 0.01.
Perhaps this is also related to the decimal problem I found in text gauges where the rounding of numbers is not done correctly ?
Or does this have to do with the other (3rd!) decimal problem found in calculation events ?

OS: windows 7 Professional SP1, Decimal symbol setting = '.'
PV: 2.7.10319
Device:PV780(10key)

I hope you can fix this asap...

We would be glad to help. If you could can you give me more details about the issues your having.

First Issue. I have checked and the problem entering decimals in visible conditions is corrected in the upcoming patch.

Second Issue. There is an issue around rounding on gauges when the value is between 0 and 1 that we have had on the backlog for a while. Is this the issue your seeing? Or are you referring to something else. There are some behaviors that are often a struggle for people around the Smallest Increment feature that causes it to appear to round wrong.

Third Issue. Can you tell us what issue you have had with calculation events? I don't see that you have logged anything related to this?

Let us know and we will take look.

Hi,

Add 2)
The rounding of values in specifically text gauges is still a problem. It is not only that the rounding is wrong when the input value is halfway between between 0 and 1, but also the sign (!) changes.
So when you put in a value (J1939 parameter) that corresponds to around -0.5 you expect the rounding to result in either 0 or -1 when using no decimals.
Instead you will see the value +1 !

Remarkebly the problem occurs for both the pv750 and pv780, but one has this for an input value of -0.5 the other at a input value of +0.5 (with the resulting incorrect value of -1).

Add 3)
I tested this with pv2.7
Example of calc event that converts conditionally km/h to mph value.

if (SpeedUnitIsKmPerHour=1, J1939_VCU_2Minus39__VCU_Vehicle_Speed, J1939_VCU_2Minus39__VCU_Vehicle_Speed/1.609)

This will result in an error in the 1.609 value if my windows 7 Decimal Symbol is set to ',' in stead of '.'
Here in norway the default is apparently ','.
Changing the value 1.609 to 1,609 will result in other errors.

The error msg in the Event log says: Error in expression Calculate VehicleSpeed. Expression is not valid
Although the Edit Expression window says: Validation was successful.
Probably you do validation on two places ?

NB.

I was under the impression that you have already been working on 2)+3).
Both were reported several months ago through your office in the UK.

I hope you can fix 2) very soon, because I have no other solution. I have been given a kind of work around in the past. But in my opinion is the result of this not gauranteed and I would have to check/modify all my variables for this behaviour. That is just ridiculous.
I have the opinion that i have found a real bug, that should be easy to fix.

I'm not sure where the ball got dropped on issue 2 and 3 but we will take a look and see if we can get it in this patch. Issue number 2 is one that's been out there a long time. Its specific to rounding between 0 and 1 and is only present when using the smallest increment feature. But we will take a look and see if there is a solution or at least a work around.

The third issue hasn't been reported that I know of but there have been recent changes to how we manage these type of issues and it may be in a backlog with no correction.

I'm sorry for your frustration. If the bugs turn out to be easy, we will get them into the upcoming patch.