Function Sin,Cos in the sysmac studio

[Ricky87]

Good morning everyone, I'm having difficulty using the "sin" and "cos" functions in sysmac, in particular the results of the functions are not correct, for example if I convert 180° into radians, with the result 3.14159 and then I do "sin", the result is -8.74227 when it should be 0. Could anyone tell me how to solve the problem? Thank you all

 

[drbitboy]

The result shown is "-8.74227.." i.e. it ends with two full-stops, which could be two-thirds of an ellipses, so perhaps we are not seeing all the digits and characters in the sin(3.1415927) result.

I suspect that the value of the displayed result, if we could see all the characters, is actually something like -8.74227E-07, which is near enough to zero for most purposes.

Is there another place you can view the value of the tag that is named seno?

Welcome to the forum!

 

[Ricky87]

In fact I noticed it, but the result, even if close to 0, is wrong because it really is 0

 

[plvlce]

In fact I noticed it, but the result, even if close to 0, is wrong because it really is 0

sin(π) is 0, but sin(3.1415927) is not.

Your input is not perfectly accurate (having been rounded when converting to radians) so why do you expect your output to be perfectly accurate?

 

[Steve Bailey]

but the result, even if close to 0, is wrong because it really is 0

The value for PI obtained by the DEG to RAD conversion isn't "correct". That may be why the SIN function returns an "incorrect" value. The problem is that you don't have a powerful enough processor to obtain the "correct" value for PI. Of course, nobody else in the world does either, so stop obsessing over on error of 0.00000087. I doubt if you own a device capable of measuring that amount of error in any meaningful units.

Edit: If great minds think alike, then apparently plvlce and I have great minds!

 

[Ricky87]

Thank you for the explanation and I apologize to you

 

[drbitboy]

I apologize that my answer was incomplete, others mentioned the roundoff issue, which I thought would be obvious (the classic mistake: thinking we are normative).

If it really matters, then you could add a rung that conditionally assigns a value of 0 to seno, with the condition being that the value of grad is a multiple of 180.

But in reality, the only reason to ensure seno is exactly 0 is if there is a equal-to comparison of seno to zero somewhere else in the program, in which case that comparison can be replaced with a check whether grad is a multiple of 180.

 

[Ricky87]

Thanks for your patience. Is there a function that allows you to read only the first two decimal digits of a REAL variable and excludes the subsequent ones?. Thank you

 

[parky]

Perhaps DR will have an answer, but I did (as others) post some code where it allowed for rounding up or down i.e. if digit 3 of the decimal was 5 or greater round up if less then round down (more accurate) but a simple one is take your value times it by 100.0 convert it to integer, Then back to a real then divide it by 100.0

 

[drbitboy]

Perhaps DR will have an answer, but I did (as others) post some code where it allowed for rounding up or down i.e. if digit 3 of the decimal was 5 or greater round up if less then round down (more accurate) but a simple one is take your value times it by 100.0 convert it to integer, Then back to a real then divide it by 100.0

Assuming OP means the first two decimal digits after the decimal point, this looks good to me.

 

[Peter Nachtwey]

This is a basic numerical analysis problem.
The posts above that say the answer is not going to be perfect are right. This is especially true if there is only 32-bit REALs.

However, your technique needs to be improved if you want better accuracy. The solution is never take the sin() or cos() of an angle greater than 45 degrees. This requires some tests before doing the sin() and cos() functions. It should be easy to see that 180 degrees can be converted to 0 degrees but negate the cos() result. There are 4 + or - 45 degree sections in a 360 degrees.

This is important because the sin() and cos() function use a Taylor series in radians to compute the results. The OP is passing PI to the trig functions and when taken to the 7 power, the numbers get to be very big. However, if you convert the numbers to range of -45 to 45 degrees, this results in a number of less than 1 in radians. A number less than 1 taken to the 7th power will be very small and this will result in a more accurate answer. It is best to avoid using a wide range of numbers when using floats. This avoids losing precision because there are only 23 bits of mantissa.

Now if the PLC's sin() and cos() functions were written properly, these functions would do what suggested behind the scenes.

 

[Ricky87]

Thank you all for your detailed explanations. There is always something to learn from others and we will never stop doing it. However, I think I solved it by using the "DispartReal" function to pass "0" when the exponent is less than "-8". I'll post some screenshots. Thanks again

 

[Peter Nachtwey]

You covered up the problem but what about all the cases when the angle is big?

 

[Ricky87]

You covered up the problem but what about all the cases when the angle is big?

For example?

 

[Peter Nachtwey]

You have your example with 180 degrees. What if the angle is 270?