[S7-1500] Valeur REAL bloquée

[Damall]

Bonjour,

je fais une bête opération d'addition, et le résultat reste bloqué à 32768.0.

Je ne comprend pas.

Si quelqu'un a une explication ?

J'ai essayé avec une variable REAL dans un DB et un MD, mais ça ne change rien.

[jeanluc69]

Bonjour
2 remarques:
tu utilise #Temp_REAL un peu partout . En sortie du DIV:OK
En entrée du MUL: ok en sortie du MUL et en entrée du SIN .La prend une autre variable #Temp . On ne sais pas qui lit ou ecrit quoi et dans quel ordre les instructions sont exécutées. Met le MUL après le DIV et le SIN apres le MUL

Quand au ADD, pas pigé: Le bloc est toujours valide. Tu incremente a chaque tour de programme !!!

[Damall]

Salut,

il n'y a pas de soucis avec les variables Temp_REAL. ça fonctionne très bien.
Si tu regarde bien le code, les variables sont écris et lu dans l'ordre qu'il faut.
Et oui, le bloc ADD est appelé à chaque tour de cycle.

[Damall]

Apparemment l'utilisation des variables de type REAL doit se restreindre à 2 chiffres après la virgule.
Mon incrément de 0,001 ne passe pas.
Si on veux plus, il faut passer sur des variables de type LREAL, avec lesquels on peux aller jusqu'à 9 chiffre après la virgule.

[MiGaNuTs]

Apparemment l'utilisation des variables de type REAL doit se restreindre à 2 chiffres après la virgule.
Mon incrément de 0,001 ne passe pas.

C'est un peu plus compliqué que ça.

Les réal sont codés avec, selon leur "taille", un certain nombre de bits qui servent a coder la position du zéro (l'exposant), et le reste des bits qui sert a coder les chiffres "signifiants".
quand tu additionne une valeur qui est très petite a une qui est très grande, la petite est trop "loin" de la virgule de la grande, du coup elle n'est pas "significative" par rapport a la grande, elle est plus petite que l'arrondi de la grande valeur et du coup ça revient a additionner zéro.

En utilisant des LREAL tu peut rencontrer le même problème, tu l'aura juste une fois que ton "grand" nombre aura atteints une valeur beaucoup plus grande.

De manière générale avec les flottants quand tu fait des calculs, plus les exposants des valeurs de ton calcul sont éloignés, plus tu a une "grosse" erreur d'arrondi. Et quand tu fait beaucoup de calculs a la suite tu risque d'avoir un résultat avec un arrondi dégueulasse, voire complétement faux.

https://fr.wikipedia.org/wiki/Virgule_flottante


edit:

Pour faire plus simple, pour n'importe quel processeur (1*10^32) + (1*10^-3), bah ca fait 1*10^32
Et un matheux te dira que c'est pas tout a fait vrai, mais osef, on va dire que c'est bon.

[Damall]

Merci pour tes explications beaucoup plus précise.

[JC87]

Bonjour,

Je rajouterai à l'explication de MiGaNuTs que pour palier à ce probléme il y avait dans la libraire OSCAT un bloc fonction pour faire des additions de REAL en double précision. J'avais du l'utiliser pour des comptage d'énergie ou je rajoutais des watts à des kilos voire mégawatts. je ne sais pas si ça existe aussi pour TIA mais ça doit pouvoir se convertir puisque ce sont des blocs en SCL.

JC

[steph68]

Salut,

Un REAL a 23 bits de mantisse (ce qui sert à coder la valeur sans tenir compte de la position de la virgule) soit 2^23 = 8 388 608. On peut dire qu'il y a presque 7 chiffres significatifs.

Un LREAL a 52 bits de mantisse, soit 2^52 = 4 503 599 627 370 496 --> soit presque 15.5 chiffres significatifs.

Donc 32768.001 s'écrit sur 8 chiffres > 7 chiffres significatifs --> tu perds la précision.

Il faut que tu passes en LREAL.

@+

[JC87]

En me relisant je m’aperçoit que le bloc fonction dont je parlais dans la librairie OSCAT simulait en fait un LREAL, type de donnée qui n'existait pas en Step 7. Évidement comme ça existe en TIA sur du 1500 il n'y aucune raison d'utiliser le bloc en question. Fatigué le JC heureusement ce soir c'est les vacances

JC

[itasoft]

Slts,
Lancement d’une nouvelle polémique, LOL
Un bon automaticien n’utilise jamais de REAL (sauf quand il n’a pas le choix)
Ex : si le traitement est en grandeur physique kg il travaille en grammes avec des DINT