[sinha_nsit]

A value, arising out of a macro calculation, lying between -10exp-29
and +10exp-29 (but not equal to 0) is not permitted, generating an
alarm condition (CALCULATED DATA OVERFLOW).

However, a programmer may desire that the control should ignore
this "error”, and treat any value in this range as 0. This might be
possible through a parameter setting. Can you please let me know
this parameter.

6004#1 is for a different purpose (only for SIN, COS and TAN), and
does not work in this case.

Thanks.

[stevo1]

What is the code that you are getting the alarm from? I don't know of a parameter that change adjust that.

What i do to not allow the over calculation or leading 0's to calculate to far is use the ROUND function. Even if you need a accurate number say 5 places past decimal you can use the round to make sure you get .00001 ect.

Stevo

[sinha_nsit]

My question is purely of academic interest, which is not likely to occur anytime. Consider the following:
#1 = .00000001
#2 = #1 * #1 * #1 * #1
This would generate an alarm because #2 is less than 10 exp(-29).

However, this is a case of mathematical underflow, and can be treated as 0, for further calculations. But, the control does not do that. Possibly, there might be some parameter for this to happen.

[HansenMonk]

I'm having [+Underflow] errors on simple calculations too - which is strange.
I don't quite understand how underflow works..

Example:

#101=0.5
#102=0.1
N5000G52Z#101
(Random CYCLE)
(Random CYCLEend)

IF[#101EQ0]GOTO5001
#101=#101-#102(0.5-0.1 until -0.1)
IF[#101LT0]THEN#101=0(Force Null)
GOTO5000
N5001

This is a straightforward macro which should always end up at #101=0 in 5 runs.

I randomly get [+Underflow] on #101 and it shouldn't be possible. Apparantly either 0 isn't actually 0(i.e. 0.000000001) or 1 (1.00000000001) is the problem.

From #101=0.1 to #101=[+Underflow]

In my code this forces a repeat of #101=0 once.

First as [#101=+underflow] and finally as [#101=0]:
After the [+underflow] goes through the macro it turns #101 into '0' and runs through the macro-loop a final time.

Sometimes you get [+Underflow] error on '0' value as well.. and there's nothing I can do about it.. for now..

[HansenMonk]

+Underflow bypass:

#101=0.5
#102=0.1
#103=#101(<- BYPASS VALUE)
N5000G52Z#101
(Random CYCLE)
(Random CYCLEend)

IF[#101EQ0]GOTO5001(END)

IF[#101EQ0.1]THEN#103=0(FORCE NULL)
IF[#103EQ0]THEN#101=#103(FORCE NULL)
IF[#103EQ0]GOTO5000(FINAL CUT)

#101=#101-#102
GOTO5000
N5001

I can't fix the actual underflow so I bypass the error by having a macro to set to 0. It works but it's very backwards programming.

[deadlykitten]

hy hansen regardless of cnc brand, or pc software, 0.5 - 0.1 is not always 0.4

thus 0.5 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 is not always 0

that's because of variable's nature/type that holds that data

to fix your code, consider a tolerance, like #101=5, if ABS[#101-5]<=0.0003 then do something

Apparantly either 0 isn't actually 0(i.e. 0.000000001) or 1 (1.00000000001) is the problem.

for this instance, 0.0003 has to be small enough not to affect your calculations, but also bigger than 0.00000000001

please feel free to ask anything / kindly

[HansenMonk]

I do not understand. Can you give examples in code?

So 1+1 does not =2.. it's >2? That's weird and dangerous.

[deadlykitten]

hello indeed, at 1st glance, it seems weird and dangerous but once you get into things, it all makes sense

as you cut metal, etc, i guess you notice that the metal cutting is not always identical, but the part is good if you are in tolerance; for example, if you have to deliver 50+0.1, then all parts may be 50.02 50.03 50.05, etc, their variation does not matter, as long as withinh tolerance

same aplies to whatever accuracy needed : the cutting process is not a precise 0 accuracy thing, but stable within a given tolerance

i hope is all ok so far

software handles variables with data types, and each type has a given accuracy : for example, for 5, you can use an "integer" type that will hold 5, but will never allow you to hold decimals, like not possible to hold 5.1 or not eve 5.0

to handle decimals, then you need a "real" type, that has 15 digits suport, but a trust accuracy until 7th digit; for example, in such a system, 5 will be 5.0000000215454, thus 5 foloowed by accurate 7 digits, then followed by noise

actually, each value in computers is noise affected, and the data type simply ensure that the noise does not affect the tolerance

even more, a data type for siimple numbers, like 5.232, 100.311, is not the same as one for big numbers, like exponential, or astronomcal lengths, that are designed to operate and be accurate in another range

please feel free to ask anything / kindly

[HansenMonk]

Thank you for the simplified explanation. Imagine that... I never thought to consider "noise" as a thing - but as I read this it makes sense.

Is it then reasonable to say that the older the computer is (i.e over 15 yrs) the more prevalent such deviations become? Esp. considering environmental wear and tear..

[deadlykitten]

I never thought to consider "noise" as a thing

life is where the "noise" begin otherwise is monotonous

pc operates on 0 1, each having a bandwith; these bands are not near, but separates, as any signal that falls in between to be ignored, keeping the 0 always in a region, and 1 in another region; thus the 0 & 1, inside a computer, operate in a tolerance zone, and those zones are far apart; if you repeat a data transmision for 100 times, then there may be some signals that fall between 0 & 1, yet all those transmisions will be succesful, as reach row of data is being checked, and if the receiver does not match the transmiter code, then simply requires to retransmit the data; is possible that 2 different data sets to have same identification code, but with very low chance in practice so again, data transmision is tolerated ...

bases for sofware requirement for cnc are from the 90s, whatever else is there, is to get money out of your pocket there are deals between hardarware producers and software producers, as to ensure a colateral win-win, and some requirements are not actually needed by the software, but are put there as for the customer to buy the most, or as recent hardaware as his pocket permits ... if you take the last windows 10, and remove all "unecesary" things from it, you get a very high step in performace, as most of it is not actually for your benefit, but to track you ...

also default data types have not changed in the last 15 years; there are users with old hardware, still doing their work; onestly, i also like older versions, but recently i no longer care about the device, as data safety and easy acces to it from different places is a must; data is more important than the device

---

back to overflow errors, sometimes you may need to change the syntax; for example, if a=b, or if a-b=0, or if a/b=1, they all seem to be identical, yet each case can trigger overflow at different moments / kindly

[deadlykitten]

please consider to check the parameter, as described by sinha in 1st post; i am not a fanuc guy, i can't help

"true" random number generator algorithms are noise based