PLC texte Structuré, convertir un nombre décimal en réel(float). Ne pas obtenir la valeur je pense. (IEEE-754)

J'ai un matériel qui est en communication avec l'AUTOMATE via Profibus DP, qui envoie
moi 4 octets de données en hexadécimal, c'est "44 79 FF FF" et dans le programme de PLC j'ai déclaré
un tableau d'OCTETS pour cette entrée de données. Le problème est dans l'AUTOMATE les données que je reçois dans mon OCTETS
tableau est "66 121 255 255" qui est la valeur décimale de la séquence hexadécimale, mais mon but est de
convertir une valeur à un RÉEL et quand je fais ça, je ne suis pas la valeur que j'ai prévu.

J'ai créé une valeur DWORD(4bytesData) que j'ai insérer tous les OCTETS.
Donc, avant de me insérez les 4 octets en 4bytesData les octets sont: in1 = 68 , in2 = 121, in3 = 255 & in4 = 255

4bytesData := (SHL(SHL(SHL(BYTE_TO_DWORD(in1), 8) OR BYTE_TO_DWORD(in2), 8) OR     BYTE_TO_DWORD(in3), 8) OR in4);

realValue := DWORD_TO_REAL(4bytesData);

Où in1, in2, in3 & in4 est d'octets 0-3.

La valeur que j'obtiens est; 4bytesData = 1148846079 & realValue = 1.148846 e+009

La valeur que je m'attends à recevoir de realValue est = 9.9999993896484375E2

Si j'utilise ce site (
IEEE754 de l'Analyseur/Convertisseur ) et la conversion de la valeur hexadécimale (4479FFFF) je me fais de la valeur que je veux, et si j'insère la valeur décimale (1148846079) je me fais la même valeur que je reçois dans le PLC.

J'espère que vous comprenez mon problème,
Merci beaucoup à l'Avance.

OriginalL'auteur hijack | 2013-04-18

  1. 4

    Vous l'avez déjà compris, il semble que vous venez de ne pas s'en rendre compte. La conversion DWORD_TO_REAL est de prendre l'entier (hex) valeur stockée dans 4bytesData et de le convertir en format IEEE754.

    Ce n'est pas ce que vous voulez faire. 4479FFFF est déjà en format IEEE754 - vous êtes de prendre de la valeur, l'interprétation du RÉEL comme une valeur DWORD, puis la conversion de la valeur DWORD à un RÉEL. La réponse courte est que vous n'avez pas besoin de conversion - 4bytesData est déjà dans le bon format.

    modifier

    suivre les commentaires :

    PLC texte Structuré, convertir un nombre décimal en réel(float). Ne pas obtenir la valeur je pense. (IEEE-754)

    ici FunctionBlock2 delclares rIn(RÉEL), de la déroute(RÉEL) et définit rOut:=rIn;. Cela permet de contourner la contrainte typecasting de SAINT. Rien ne change sur les données stockées dans D2000 ici - c'est la même forme de données binaires. Le haut bloc de fonction est le stockage dans la mémoire et celui du bas est la lecture de la mémoire. La seule différence est que l'échelon supérieur est de l'interpréter comme une valeur DWORD (pour l'affichage) et le bas de l'échelle est à interpréter comme RÉEL.

    modifier

    J'ai lu le Beckhoff manuel. Il semble que vous pouvez avoir d'autres options. Essayez peut-être en déclarant une valeur DWORD et RÉEL à la même emplacement de mémoire. Si non, peut-être les pointeurs de vous laisser faire cela (pas sûr si le type de restrictions s'appliquent également aux pointeurs avec Beckhoff?)

    Merci pour la réponse. Il est exact que je n'ai pas à utiliser le "DWORD_TO_REAL" la conversion. Mais je suis encore en train de la "1.148846 e+009" valeur si je le supprimer, donc c'est toujours la même. Le 4bytesData est "1148846079".
    c'est probablement de faire la conversion automatiquement pour vous, alors, même si vous retirez la conversion explicite...dépend de l'AUTOMATE que vous utilisez. Essayez de déclarer 4bytesData comme type RÉEL plutôt que sur valeur DWORD.
    Ouais c'est probablement. (Je suis en utilisant Beckhoff) Quand je suis en train de faire le transfert des octets dans la 4bytesData j'obtiens une erreur: "incompatibilité de Type en paramètre, impossible de convertir de 'RÉEL' à 'OCTET'.
    pouah... je déteste texte structuré. Juste sortie comme une valeur DWORD sans avoir à les convertir et de l'utiliser comme une VÉRITABLE dans le ladder, il va fonctionner.
    J'ai lu les Beckhoff manuel. Il semble que vous pouvez avoir d'autres options. Essayez peut-être infosys.beckhoff.com/content/1033/tcplccontrol/html/... -- déclarer une valeur DWORD et RÉEL à la même emplacement de mémoire. Si non, peut-être des pointeurs de vous laisser faire ça (je ne sais pas si le type de restrictions s'appliquent également aux pointeurs avec Beckhoff?) infosys.beckhoff.com/english.php?content=../content/1033/...^.htm&id=14183

    OriginalL'auteur J...

  2. 0

    Votre ordre d'octet est probablement erroné et que votre routine attend en face de endianness. Essayez FFFF7944 au lieu de 4479FFFF et voir si vous obtenez 9.9999993896484375E2 comme prévu. Aussi, 1148846079 est 00F4884E comme IEEE754 (changement d'ordre des octets si besoin est) de sorte que vous pourriez avoir plus d'une erreur dans votre perception.

    Bonne idée. Mais quand j'ai changer l'ordre-je obtenir: 4294932804(décimal) et 4.294933 e+009(réel).
    Ouais, je ne comprends pas pourquoi je reçois 1148846079.. Le PLC doit être en train de faire la conversion de certains que je ne suis pas au courant.
    Je comprends maintenant. Vous devriez lire l'aide pour DWORD_TO_REAL(). Il paraît que vous attendez avec impatience octets représentant la norme IEEE754 format flottant (qui est une perception erronée de cette fonction), mais au lieu de cela il vous permet de convertir par exemple 4 à 4.0 et 1000 à 1000.0. Vous avez besoin de trouver une fonction qui va de fonte brute IEEE754 4 octets pour un nombre réel, ou écrire ces 4 octets dans le bon endianness commande directement à un nombre flottant octet par octet.
    Ah okey, je vais essayer ça, merci.

    OriginalL'auteur avra

  3. 0

    être prudent de nidification toutes les SHL. DANS la V2.3-vous ne pouvait pas aller sur 4 de profondeur. J'ai trouvé sur différents contrôleurs (compilateur pour la cible probablement) que vous pouvez avoir de mauvaises évaluations par de nidification. Mieux les garder sur leurs propres lignes. 4 lignes de code à mettre dans une fonction, la FONCTION BYTES_TO_DWROD : DWORD et vous sont tous bons pour la réutilisation de votre conversion.

    OriginalL'auteur Steve Pfeifenroth

  4. 0

    Utiliser un pointeur pour déplacer la valeur de la valeur DWORD pour le RÉEL. Il semble empêcher la conversion.

    OriginalL'auteur user6415393

  5. 0

    Si quelqu'un est intéressé, j'ai fait cette fonction qui fonctionne sur un Beckhoff PLC pour convertir à partir d'un tableau de 4 octets pour un vrai:

    (* déclaration *)

    FUNCTION BYTE_TO_REAL : REAL
VAR_INPUT
abValueIn : ARRAY[0..3] OF BYTE;
END_VAR
VAR
pByteIn1, pByteIn2, pByteIn3, pByteIn4: POINTER TO BYTE;
rValueOut : REAL;
END_VAR

    (* mise en œuvre *)

    pByteIn1 := ADR(rValueOut);
pByteIn2 := ADR(rValueOut) + SIZEOF(BYTE);
pByteIn3 := ADR(rValueOut) + 2 * SIZEOF(BYTE);
pByteIn4 := ADR(rValueOut) + 3 * SIZEOF(BYTE);

(*watch out, small endians needed here*)
pByteIn1^ := abValueIn[3]; 
pByteIn2^ := abValueIn[2]; 
pByteIn3^ := abValueIn[1]; 
pByteIn4^ := abValueIn[0]; 

BYTE_TO_REAL := rValueOut;

    Que je l'ai trouvé, VRAI est stocké sur 4 octets, fort de l'octet à la fin. Je veux dire que, par rapport à La norme IEEE-754 convertisseur, les octets sont triés dans l'autre sens, j'ai donc pour l'inverser dans le code.

    Je n'attrape pas le problème d'origine avec décimal - hexadécimal. Dans twincat IDE, la valeur sont affichés décimal en debug, mais en interne, cela ne devrait faire aucune différence

    OriginalL'auteur claude joliat