Forum automatisme

non tu ne le convertis surtout pas.

tu déclares ta première variable en REAL
puis une structure (ou un tableau de 2 WORD) avec le mot-clé AT
il faut le faire en SCL, AT ne marche pas dans les autres langages.

ta structure va occuper le même espace mémoire que ton REAL
c'est la bonne façon de faire un chevauchement mémoire de plusieurs variables, en conservant un adressage symbolique.

la saisie du mot-clé AT est un peu capricieuse, regarde l'aide de TIA

@+

EDIT: AT marche dans tous les langages sur les S7-1200 / 1500

Alors... j'ai un peu galéré our le AT en effet
En fait il faut déclarer dans type de donnée, le AT en dessous de la variable qui t’intéresse et ensuite ça le créé. ne reste plus qu'a faire la variable en array ou struct.

Alors j'ai refait un bout de prog et on y est presque : Mon but et que les valeurs du output_value1 et 2 (version actuel du real séparé) et le output1 et 2 (version que je suis en train de faire avec vous) soit identique.
Le Output1 est ok mais pas le 2
j'ai programmé comme suit : J'aimerai tellement y arriver...

PS : la valeur dans input est une valeur fixe pour le moment, pour les tests

steph68 a écrit : ↑10 nov. 2023, 11:02 non ce n'est pas comme cela que ça marche
c'est un complément à 2 de la valeur : https://fr.wikipedia.org/wiki/Compl%C3% ... C3%A0_deux
et le bit le plus significant témoigne de ce complément à 2 : c'est le fameux bit de signe

donc si j'ai -1 soit 16#FFFF_FFFF en 32 bits signé, j'aurai toujours -1 soit 16#FFFF en 16 bits signé.

@+

Le fait que la "valeur" soit codée différemment en fonction de l’état du bit de signe ne change rien a l'affaire,un bit contient l'information du signe, et les 15 (ou 31) autres contiennent bien l'information de la "valeur".
Si je mets des "" c'est pas pour rien, c'est pour montrer que je vulgarise et que je n'entre pas dans les détails qui n'ont pas d’intérêt par rapport a ce que j'essaie d'expliquer.

Quand au découpage avec des masques et des rotations, effectivement ça marche dans le cas particulier de FFFF_FFFF. Mais dans le cas ou tu a des trucs du genre xxxx_8xxx, le bit qui dans ton DINT vaux 2^16, bah un fois coupé il représente le signe dans le INT du poids faible et plus 2^16.

MiGaNuTs a écrit : ↑09 nov. 2023, 17:44 alors la en effet c'est plus chiant.
J'avoue qu'il faut que je réfléchisse un peu plus a la question, parce que les nombres négatifs c'est un peu pénible a gérer

J'ai toujours pas pris le temps de creuser, mais c'est sur qu'a partir du moment ou tu a 2x la même info (le bit de signe) après le découpage et toujours le même nombre de bits pour stocker l'information complete de "valeur", y'a forcement un moment ou tu a une couille. Ne serait ce que pour l'affichage.

steph68 a écrit : ↑09 nov. 2023, 19:49 un shift est aussi beaucoup plus rapide à l'exécution (qui s'en soucie de nos jours ?)

Sur les processeurs modernes, oui. Sur les vieux coucou 8 bits avec lesquels j'ai appris a coder, ça dépends du processeur, du langage, et surtout du compilateur (ou de l’interpréteur). A l’époque ou j'était ado et ou j'avais que ça a foutre je l'ai testé sur diverses machines.

Mais comme tu dit, sur les processeurs modernes on s'en fout du temps de cycle.Y'a plus personne qui code sur Z80 aujourd'hui (du moins pas de trucs pro, parce sur la scène CPC y'a encore quelques mecs qui font des trucs de fou).
Je continue a faire des divisions juste pour emmerder les puristes.

commence par faire pointer input_1 et input_2 sur %MW18 et %MW20 (et pas %MW19)
tu n'es pas chez Schneider.

Le résultat du AT est juste, c'est ta première méthode qui est fausse.

tu comprends pourquoi avec l'adressage absolu c'est le mal absolu ?

@+

steph68 a écrit : ↑10 nov. 2023, 13:54 commence par faire pointer input_1 et input_2 sur %MW18 et %MW20 (et pas %MW19)
tu n'es pas chez Schneider.

Le résultat du AT est juste, c'est ta première méthode qui est fausse.

tu comprends pourquoi avec l'adressage absolu c'est le mal absolu ?

@+

Comment tu explique que j'ai la bonne valeur sur mon enregistreur de l'autre coté si ce n'est pas juste ?
De plus, les %MW correspondent à 2 bytes donc %MW18 et %MW19 correspondent bien au Dword %MD18, qui lui est sur 4 bytes! non ?

si tu le dis ... moi je m'incline devant ton expertise

commence par afficher la valeur hexa de tes INT, et la valeur hexa de ton REAL (il y a des sites web qui te font ça online - google IEE754 online converter) et reconstitue le puzzle.

amuse toi bien.

@+

Sinon y'a aussi la calculatrice de windows en mode programmeur. Mais bon, son ergonomie est plutot douteuse.

steph68 a écrit : ↑10 nov. 2023, 15:38 si tu le dis ... moi je m'incline devant ton expertise

commence par afficher la valeur hexa de tes INT, et la valeur hexa de ton REAL (il y a des sites web qui te font ça online - google IEE754 online converter) et reconstitue le puzzle.

amuse toi bien.

@+

Reconstituer le puzzle ? j'ai meme pas toute les pièces : J'ai moins de 1 dans la partie faite récemment.... casse tête a la noix

tu le vois le décalage d'un octet maintenant ?
je sais même pas pourquoi je continue à répondre

Je n'ai pas tout à fait compris ce que tu veux faire mais il faut prendre en compte les éléments suivants d'une variable de type real:

Les opérandes de type de données REAL ont une longueur de 32 bits et servent à représenter les
nombres à virgule flottante. Un opérande de type de données REAL se compose des trois
éléments suivants :
• Signe : Le signe est déterminé par l'état logique du bit 31. Le bit 31 peut prendre les valeurs
"0" (positif) ou "1" (négatif).
• Exposant de 8 bits en base 2 : L'exposant est augmenté d'une constante (base, +127) afin de
représenter la plage de valeurs de 0 à 255.
• Mantisse de 23 bits : Seule la partie décimale de la mantisse est représentée. Dans le cas de
nombres à virgule flottante normalisés, la part de nombres entiers de la mantisse est toujours
égale à 1 et elle n'est pas mémorisée.
Le type de données REAL est traité avec une précision de 6 chiffres.