7/8/2016 1:44 PM  
Posts: 29 Rating: (0) 
Hello Everyone, Looks like I'm stumped again. I have a simple polynomial calculation (7th order) where the result in SCL is "NaN". Not sure why, I'm not doing any root or logs that might make the calculation sensitive to negative numbers or certain values.
I specifically get a NaN result for "Exc1OverlapActTemp" when Exc1Angle = 0.0. But as you can see in the image I took all the values used in the polynomial are nonzero (some negative, some positive) and the result is NaN. Any ideas? ****Also A further point, the value actually changes to NaN when Exc1Angle is less than ~4.5. Then at some larger magnitude negative number it goes back to value again. My thinking is that "GatActTemp" is near zero in this range and the exponent of the internal register when it takes it to the 6th power is too large in magnitude (~e16 at 0). Is this a result of going out of range on the floating point exponent? I'm looking through the documentation now looking for the limitation of the S7416 controller. Just checked this again, S7 32bit real should support e32! Now I"m still stumped. 
Last edited by: Nate@SMS at: 7/8/2016 2:07:10 PMLast edited by: Nate@SMS at: 7/8/2016 2:10:45 PM 

7/8/2016 2:12 PM  
Joined: 9/23/2005 Last visit: 3/24/2023 Posts: 4129 Rating: (634) 
Don't have idea why NaN. But a little hint  use Horner's method for calculating poly value. 
Regards, 

7/9/2016 6:39 AM  
Joined: 1/28/2009 Last visit: 2/21/2023 Posts: 6794 Rating: (1341)

Dear Nate@SMS , To have a better discussion and providing strong reasons , we need to have your program section , test and see what would be the exact reason.About the limitation in floating point calculation , check the following link: How accurately can I calculate with REAL numbers that are used in extensive formulas?
The final point ,see if "Neperian logarithm" helps in case of multiplication of huge numbers by small numbers. I hope it helps, hdhosseini 
7/9/2016 10:18 AM  
Joined: 9/8/2009 Last visit: 3/15/2023 Posts: 1410 Rating: (146) 
The correct use of multipier in SCL is * and not **. Use all operators in a correct way, first. Second, when using floating point numbers, alyways use decimal points for constants. In your exaple you are using numbers like 2,3,4,...instaead of 2.0, 3.0, 4.0,... 
Last edited by: Marko Bursic at: 7/9/2016 10:21:32 AM 

7/9/2016 10:21 AM  
Posts: 8946 Rating: (994) 
result out of allowed numeric area / divison by Zero (?) 
7/9/2016 6:13 PM  
Posts: 5225 Rating: (1165) 
Hi there. I am very curious about this case.. What result did you expect? Sorry  TIA Portal is what I have available. Maybe someone wants to build on the code run on an S7300 / S7400? Greetings.
AttachmentS71200_SimResult_and_SCL_code.zip (71 Downloads) 
Last edited by: William_B at: 7/9/2016 6:17:45 PMadd inline picture and code 

7/11/2016 8:29 AM  
Joined: 9/23/2005 Last visit: 3/24/2023 Posts: 4129 Rating: (634) 
** is an exponentiation. 
Regards, 

7/11/2016 9:16 AM  
Posts: 29 Rating: (0) 
Hello Everyone,
From a standpoint of optimal computational accuracy, you are all right, there are much better ways to do this. Probably the most accurate method is to solve for the roots of the polynomial and factor it, that way the numbers are not so radically different when the math is computed. Problem is this polynomial has 5 imaginary roots and would be really messy to pull out the only 2 real ones, although it'd help a bit from a standpoint of accuracy. HOWEVER, my problem has nothing to do with accuracy. S7 doesn't throw NaN or any other errors if you're doing doing the most optimal calculation, it'll just round. So that's not my issue. My issue is much stranger. Turns out in SCL, I cannot take the power of a negative number greater than 2!!! This seems like some sort of mistake with the hardware/software, and at this point I need to look at the STL generated block to understand the problem, but take this much more simple example. This code here works fine for the smallest REAL, positive value that S7 can represent:
Also, if GapAct = 0.0 it works fine as well, but any negative value, ranging from 1.0e32 to 9.9e+32, returns NaN. Furthermore, this simple logic:
Returns a value of '1.#IND00e+000' for TempB. I don't understand this value. I usually never play this card, but at this point it seems the controller or the SCL code generator is simply not doing what it should, or somewhere in the documentation I missed the statement negative values cannot use the exponent operator with values greater than 2? What's going on here? 
7/11/2016 9:38 AM  
Joined: 9/23/2005 Last visit: 3/24/2023 Posts: 4129 Rating: (634) 
I've checked William's code generated for S7300 on a simulator. Works fine. Where have you found the limits for REALs? That's the correct values: 3.402823e+38 to 1.175495e38 ±0.0 +1.175495e38 to +3.402823e+38 The code for 1**3 also is ok while simulated, i.e. the result is 1.0 as expected. Could you post whole SCL code (i.e. including vars declaration) ? 
Last edited by: jacek d at: 7/11/2016 9:42:09 AMRegards, 

7/11/2016 9:43 AM  
Joined: 9/15/2006 Last visit: 3/13/2023 Posts: 417 Rating: (71) 
As a S7 has only an EXP (base e) function and not Power, your formula is internally transferred into:

This contribution was helpful to2 thankful Users 
Follow us on