Bug in FX PLC

[DW_Microsys]

With the FX2424, the function VAL(X$) doesn't work with negative number.

Val("-1") gives 29       (29 = 30 -1)
Val("-10") gives 290    (290 = 300 -10)
Val("-101") gives 2899    (2899 = 3000 -101)
Val("-3529") gives 26471    (26471 = 30000 -3529)
Val("-35290") gives 264710    (26471 = 300000 -35290)

Please fix the bug and let me know how to upgrade the firmware.

Note: checked with FMD1616 and F2424, this bug doesn't exist.

[support]

Thank you for reporting the issue.

What is your firmware version? This bug should have been fixed since firmware release F90.4.

We are currently shipping firmware F91.0. The firmware for Fx PLCs can be field-upgraded and the downloading instructions have been emailed to you.

[DW_Microsys]

Upgrade to latest V91.0. Still have bug.

VAL("-1234.5") gives -1234 on integer, and -1234.5 on float. Which is correct.
VAL(" -1234.5") gives 1234 on integer and 1234.5 on float. which is wrong.

The difference of these two strings is: there is space in front of "-".

Please fix this one and let me know so that I can upgrade the firmware.

Thanks.

[garysdickinson]

I am in agreement with the bug in handling white space before the "-" with Fx PLC firmware. I am running V90.9.

It seems that if the first character in the string is "-" then this character is treated as part of the number to be converted. If there are white space characters before the "-", then the "-" is discarded and not treated as the first character of the numeric value.

The leading white space before the "-" is handled correctly in the simulator. This makes me think that the firmware is probably wrong.  I'm guessing that simulator is using some Java library code for emulating val().

The following test code got the result shown in the screen dump:

' TestVal - test of Val()

A = Val("-1")
A# = Val("-1")
B = Val("-10")
B# = Val("-10")
C = Val("-1234.5")
C# = val("-1234.5")
D = Val(" -1234.5")      ' white space before "-" PLC frimware reports 1234
D# = val(" -1234.5")   ' white space before "-" PLC frimware reports 1234.5
e = val("123456789")   ' appears to return signed 32-bit value
e# = val("123456789")   ' appears to return float
[/font][/color]


As with most of the TBASIC functions, very little is documented. The Val() function appears to be a bit special cased for the Fx series in that the function's return type is neither 100% 32-bit signed integer nor is it 32-bit float. It appears to be able to return 2 different types of values based on how the function is used in a TBASIC expression.  I suspect that this is not the result of a type cast but rather the TBASIC compiler evaluates each usage of val() and actually calls one of two different library functions based on how the returned value is to be used.

I bring up the return type issue for val() is represents an area of weakness in the TBASIC documentation that forces myself and others to have to constantly write test code to figure out how things actually work.  There appear to be at least 3 different numeric types handled by TBASIC: INT32, INT16 and FLOAT32.  It is very critical for the programmer to be able to predict how TBASIC's expression parser handles expressions that mix the types of variables or use any type other than INT32.  The recently added FLOAT32 makes it very difficult to predict how expressions are handled.

As the return types for most TBASIC functions are not documented, it makes it impossible to predict how expressions will be handled. Functions like val() that can return different numeric types based on how they are used in the expression simply add to the fun.

It takes lots of test code to figure out what actually happens.

Gary D*ickinson

[support]

Thank you for the bugs report.

We have just released firmware version F91.1 which made some important improvement to the PLC's handling of client connection to the 3rd party Modbus TCP server.  The reported issue with VAL(" -123.45") where a leading white space causes the negative sign to be ignored by the PLC is also fixed at the same time.

Please follow the upgrade path you received from us to upgrade the firmware.

As for the return type of VAL, Gary is right that the PLC will determine the returned type based on whether the string contains expression of floating point. If so it will return a floating point number and then it is assigned to the variable. If the variable is an integer variable and the converted data is floating point, then the floating point will be type cast into an integer (basically dropping the fractional portion after the decimal point) and assigned to the variable.

However, if the string contains no sign of floating point it will then try to convert it into an integer and depends on whether the variable assigned to receive the converted number is integer or floating point, it will be type cast into that particular format.

In order to maintain 100% backward compatibility to the integer-only i-TRiLOGI (version 6, for FMD and Nano-10 PLCs) integer data and floating point data are represented separately. Not all numeric values are automatically handled as floating point during computation. If  you want only integer math, then make sure that the terms involved in a binary operation are all integers and the PLC will perform integer operations only.  

  E.g    F# =  100/24 = 4    ' expression are all integers. So integer divide is used.
          G# = 100/24.0 = 4.16667   ' there is floating point number (24.0) so floating point division is performed.