I have noticed two errors this week using the MATH block. In one, dividing a R value by 1000 truncates the R value answer to a whole number. If I multiply instead by 0.001, the correct number works. WHY? Second, I have 4 analog inputs that I filter and scale. In one channel, the calculated number is usually the proper low number for an empty tank. Randomly, the value changes to 65535. I have placed a watch to determine the max value the variable gets to and it is 0.03, which is multiplied by 535, which never equals 65535. The memory address is not overlapped with anything else I can find (V1108). What am I missing? Thx for any help!
Announcement
Collapse
No announcement yet.
MATH Errors in DOMore
Collapse
X

Probably need to see the code, at least for the MATH box.
The analog is hard to say, but we're certainly happy to look at that as well.
If you'll send the program to support@hosteng.com, we'll check it out.
Comment

Originally posted by Shawn Lanier View PostFor my MATH issue, my box looks like this: MATH R571 "V1110 * 0.001". If I build it as MATH R571 "V1110 / 1000", it truncates the answer to a whole number.
"V1110 * 0.001" sees that you are multiplying an integer (V) by a floating point number, so it promotes the V to a float, and does the remaining of the MATH using floating point calculations.
Easy fix for the first one, just change the 1000 to 1000.0 (the floating point version of integer 1000). So, just make the expression "V1110 / 1000.0" and you should get the same result as the second one.
Basically, MATH starts out trying to do everything with integer math. Most high level languages like C, C++, Java do that. Once it hits a floating point constant, R element, or REAL function, it promotes the current integer calculations up to that point to a float, and does floating point math the rest of the way, promoting any integers it finds to float. This is typical high level language integer/float math expression behavior.
HOWEVER, we understand most nonC programmers don't know about that. We need to add a warning message to the editor to let you know of this case, where your expression is completely integer, but the result is a REAL element. Easypeasy check. Will try to bang that out for the next release.
Comment

Originally posted by Shawn Lanier View Postgood to know. I never did much beyond VB6. Thanks!
Could your analog be going negative, 1, then scaled to unsigned (e.g. V?) ends up being 65535??? 1 equals 0xFFFF, and 65535 equals 0xFFFF, one is 2's complement representation, the other unsigned representation.
Comment

Shawn Lanier, I sent you a response via email after looking at the code you sent. Let me know if that helps.
FYI, for anyone else, like franji1 says, I believe the "wrong math" is actually a case where the values being used are actually signed integers (32768 to +32767) instead of unsigned integers (0 to 65535). Hopefully, Shawn will let us know if that is true or not and if that is the issue with the "wrong math" he is seeing.Last edited by GKiser; 08032017, 09:06 AM.
Comment
Comment