Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 19 von 19

Thema: SCL: FB-Inputs/-Outputs elegant in DB schreiben und auslesen

  1. #11
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.197
    Danke
    926
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von 1513 Beitrag anzeigen
    Ja genau das meinte ich; hatte in TIA den DB geöffnet und beobachtet (die Werte mit dem orangegelben Hintergrund). Hatte zwischendurch auch mal den Wert temporär umkopiert und so. Auf jeden Fall zeigte er mal den Gleitkommawert als DWord an (16#...), und beim anderen mal (ohne LREAL) hatte die Genauigkeit des im DB gespeicherten Werts gelitten.
    Nochmal eindeutig formuliert:
    Du hast einen DB, darin ist eine Variable als REAL deklariert. Du beobachtest direkt den geöffneten DB und TIA zeigt den Wert der REAL-Variable nicht als Gleitkommazahl sondern hexadezimal (16#...) an?
    Dann ist entweder der Wert nicht als Gleitkommazahl darstellbar oder Dein TIA spinnt irgendwie.
    Wo kam der Wert her, der mittels POKE in die REAL-Variable geschrieben wurde? Welchen Wert hatte der Wert?
    Schreibt vielleicht nochwas auf die Variable, gibt es vielleicht Adressüberschneidungen?

    Wenn man das Bitmuster eines REAL-Wertes (REAL_TO_DWORD) in ein DWORD schreibt (poked) und dann als REAL-Wert interpretiert, dann leidet keine Genauigkeit, denn es ist exakt der ursprüngliche REAL-Wert. Wie sah das "Genauigkeit gelitten" denn konkret aus?

    Hast Du eine Vorstellung, wieso das Ausweichen zu LREAL und Wandeln zu REAL Dein Darstellungsproblem anscheinend löst?

    Ich habe das Gefühl, daß an Deinem Programm was faul ist und Du nun nur Symptome beseitigst statt das Problem. Wenn man ein problematisches Programm und die gefundene Umgehung nicht versteht, dann darf man das Programm nicht für eine Industrieanlage nutzen, geschweige denn den Code in häufig verwendete "Standardbausteine" einbauen.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  2. #12
    1513 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Du hast einen DB, darin ist eine Variable als REAL deklariert.
    Richtig. Genau wie der FC-Eingang (beim ersten Versuch).

    Du beobachtest direkt den geöffneten DB und TIA zeigt den Wert der REAL-Variable nicht als Gleitkommazahl sondern hexadezimal (16#...) an?
    Richtig, beim ersten Versuch bekam ich die hexadezimale Darstellung. Ich werde versuchen, das am Montag (auf der Arbeit) zu reproduzieren.

    Wo kam der Wert her, der mittels POKE in die REAL-Variable geschrieben wurde? Welchen Wert hatte der Wert?
    Im OB1 ist nur dieser eine FC, der einen REAL-Wert einliest und in die DB schreiben soll. Die Variable im DB ist auch als REAL deklariert.
    Ich hatte es zuerst mit 514.32 probiert (ich gebe die Werte aus Testgründen direkt am FC-Eingang im OB1 an). Im DB angezeigt wurde 514.313, also Fehler nach der ersten Nachkommastelle. Andere Werte wurden ebenfalls falsch übernommen.

    Schreibt vielleicht nochwas auf die Variable, gibt es vielleicht Adressüberschneidungen?
    Siehe oben, im OB1 befand sich nur der besagte FC.

    Wenn man das Bitmuster eines REAL-Wertes (REAL_TO_DWORD) in ein DWORD schreibt (poked) und dann als REAL-Wert interpretiert, dann leidet keine Genauigkeit, denn es ist exakt der ursprüngliche REAL-Wert.
    Genau das dachte ich mir auch. Ich kenne die POKE-/PEEK-Befehle ja erst seit ein paar Tagen, wenn ich mich recht erinnere, verlangt POKE einen DWORD als value. Deswegen hatte ich mir auch nichts dabei gedacht, als value REAL_TO_DWORD(value) anzugeben. Sind ja beide 4 Byte. Ich könnte mal versuchen, den FC-Eingang "Value" in "Input" zu ändern.

    Hast Du eine Vorstellung, wieso das Ausweichen zu LREAL und Wandeln zu REAL Dein Darstellungsproblem anscheinend löst?
    Absolut nicht.



    Am Montag werde ich mal alles reproduzieren. Gerne auch mit Code, um einen Fehler in TIA bei mir auszuschließen. Mich nervt vor allem, dass in AWL alles "einfach so" funktioniert hatte. L #Value, T DBD [AR1, P#0.0] oder so.


    1513

  3. #13
    1513 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Guten Morgen,

    ich fühle mich gerade von TIA verschaukelt, weil das Problem mit den Nachkommastellen nicht mehr auftritt; obwohl die Meldung
    Das Vorzeichen oder die Genauigkeit des Werts können verloren gehen.
    immer noch erscheint. Ich habe den FC-Eingang "value" davor wieder auf REAL umgestellt.

    Wenn ich im FC die Codezeile
    Code:
    POKE(area := 16#84, dbNumber := #DBNo, byteOffset := (#instno_tmp-1)*4, value := #Value);
    (instno_tmp ist eine Kopie des Eingangparameters Instanznummer)
    nutze und im OB1 den FC mit value 514.32 einfüge, dann bekomme ich im DB als Beobachtungswert 16#0000_0202 angezeigt. Wenn ich REAL_TO_DWORD(#value) nutze, bekomme ich die Gleitkommadarstellung. Und zwar die richtige; vor meinem Experiment mit LREAL wurden die Nachkommastellen falsch angezeigt. Warum auch immer.

    Das Umwandeln ins Hex-Format kann ich mir nur dadurch erklären, dass POKE einen DWORD als value erwartet. In der Hilfe ist als Datentyp "Bitfolgen" angegeben.

  4. #14
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.405 Danke für 2.002 Beiträge

    Standard

    Vielleicht nur so nebenbei ... LReal hat mit Sicherheit eine größere Datenbreite als Real ...
    Ansonsten noch einmal mein Heinweis : SCL ist nicht unbedingt für derartige absolute Speicherzugriffe gemacht und gedacht.

    Gruß
    Larry

  5. #15
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.197
    Danke
    926
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von 1513 Beitrag anzeigen
    ich fühle mich gerade von TIA verschaukelt, weil das Problem mit den Nachkommastellen nicht mehr auftritt; obwohl die Meldung
    Das Vorzeichen oder die Genauigkeit des Werts können verloren gehen.
    immer noch erscheint.
    Mich würde interessieren, wofür genau diese Meldung/Warnung erscheint. (ich habe kein aktuelles TIA)


    Zitat Zitat von 1513 Beitrag anzeigen
    Wenn ich im [...] im OB1 den FC mit value 514.32 einfüge, dann bekomme ich im DB als Beobachtungswert 16#0000_0202 angezeigt. Wenn ich REAL_TO_DWORD(#value) nutze, bekomme ich die Gleitkommadarstellung. Und zwar die richtige; vor meinem Experiment mit LREAL wurden die Nachkommastellen falsch angezeigt. Warum auch immer.

    Das Umwandeln ins Hex-Format kann ich mir nur dadurch erklären, dass POKE einen DWORD als value erwartet. In der Hilfe ist als Datentyp "Bitfolgen" angegeben.
    Die Anzeige im Hex-Format statt Gleitkomma-Format macht TIA, weil DW#16#0000_0202 nicht im Gleitkommaformat darstellbar ist - es ist eine denormalisierte (subnormale) Zahl. Das Bitmuster DW#16#0000_0202 entspricht der Ganzzahl 514 dez.

    POKE weiß nicht, was für einen Datentyp die Zielvariable hat. Deshalb erwartet POKE für den Parameter "value" einen Bitfolgen-Datentyp, welcher lediglich die Speichergröße angibt.
    Wenn man selbst keine explizite Konvertierung für einen Realwert zu DWORD angibt, dann verwendet TIA offensichtlich selbständig die Konvertierung DINT_TO_DWORD(REAL_TO_DINT(realwert)), was ich als Bug bezeichnen würde. Korrekt wäre meiner Meinung nach REAL_TO_DWORD(realwert). POKE dürfte überhaupt keine Konvertierung benutzen, welche das Bitmuster verändert. TIA sollte entweder grundsätzlich den Bitstring zu BYTE/WORD/DWORD/LWORD übernehmen oder auf einer explizit anzugebenden Konvertierung bestehen und nicht heimlich/versteckt solche sinnfreien automatischen Konvertierungen praktizieren.

    Du mußt unbedingt REAL_TO_DWORD(realwert) einsetzen.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  6. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    1513 (14.12.2015)

  7. #16
    1513 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Mich würde interessieren, wofür genau diese Meldung/Warnung erscheint. (ich habe kein aktuelles TIA)
    Die Meldung erscheint beim Übersetzen unten im Reiter "Syntax". Ich denke mal der Grund ist die Gleitkomma-nach-Hex-Umwandlung. Wie du ja weiter unten schon gesagt hast, werden in Hex-Darstellung die Nachkommastellen "abgeschnitten".


    Wenn man selbst keine explizite Konvertierung für einen Realwert zu DWORD angibt, dann verwendet TIA offensichtlich selbständig die Konvertierung DINT_TO_DWORD(REAL_TO_DINT(realwert)), was ich als Bug bezeichnen würde. Korrekt wäre meiner Meinung nach REAL_TO_DWORD(realwert). [...] Du mußt unbedingt REAL_TO_DWORD(realwert) einsetzen.
    Würde ich dann auch als Bug bezeichnen. Ob Siemens das auch so sieht


    Danke für die ganzen Infos!

  8. #17
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.197
    Danke
    926
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von 1513 Beitrag anzeigen
    Die Meldung erscheint beim Übersetzen unten im Reiter "Syntax". Ich denke mal der Grund ist die Gleitkomma-nach-Hex-Umwandlung. Wie du ja weiter unten schon gesagt hast, werden in Hex-Darstellung die Nachkommastellen "abgeschnitten".
    Steht da nicht, auf welche Anweisung genau sich die Meldung bezieht? Ein paar eindeutige Worte mehr schreiben wäre echt hilfreich. Wir können nicht sehen, was auf Deinem Bildschirm steht.
    Ist aber jetzt auch egal. Mit zusätzlich länger Nachdenken kommt meine Glaskugel darauf, daß damit die implizite bzw. explizite Konvertierung des REAL zu DWORD gemeint ist. Die Warnmeldung ist bei der impliziten/automatischen falschen Konvertierung von TIA ja ganz OK, doch bei explizit angegebenem REAL_TO_DWORD ist die Warnmeldung fehl am Platz.


    Bei REAL_TO_DWORD(realwert) werden keine Nachkommastellen abgeschnitten oder Vorzeichen entfernt. Es wird lediglich dem Compiler mitgeteilt, daß er den Wert (Bitstring) einer Variable ohne Konvertierung 1:1 in eine Variable anderen Datentyps übertragen soll. Wenn man die andere Variable im Gleitkommaformat beobachtet, dann sieht man, daß dabei nichts verloren gegangen ist.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  9. #18
    1513 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    10.12.2015
    Beiträge
    13
    Danke
    4
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Steht da nicht, auf welche Anweisung genau sich die Meldung bezieht? Ein paar eindeutige Worte mehr schreiben wäre echt hilfreich.
    Mit zusätzlich länger Nachdenken kommt meine Glaskugel darauf, daß damit die implizite bzw. explizite Konvertierung des REAL zu DWORD gemeint ist.
    Korrekt. Habe vergessen, es zu erwähnen. Ohne REAL_TO_DWORD() kommt die Meldung, mit dieser Anweisung kommt sie nicht.



    1513

  10. Folgender Benutzer sagt Danke zu 1513 für den nützlichen Beitrag:

    PN/DP (14.12.2015)

  11. #19
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.197
    Danke
    926
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von 1513 Beitrag anzeigen
    Korrekt. Habe vergessen, es zu erwähnen. Ohne REAL_TO_DWORD() kommt die Meldung, mit dieser Anweisung kommt sie nicht.
    Na geht doch. Sogar eindeutig

    Also ist die eigenartige Auto-Konvertierung von REAL via DINT zu DWORD von TIA kein Bug sondern ein Feature "mit Ansage"

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

Ähnliche Themen

  1. Wert in Array schreiben/überschreiben und auslesen (FUP)
    Von frigidolf im Forum CODESYS und IEC61131
    Antworten: 8
    Letzter Beitrag: 19.03.2015, 08:40
  2. Antworten: 3
    Letzter Beitrag: 23.11.2011, 15:26
  3. Antworten: 3
    Letzter Beitrag: 25.11.2008, 20:08
  4. Antworten: 7
    Letzter Beitrag: 30.07.2008, 13:13
  5. PS3 auslesen und Werte in MySql-DB schreiben
    Von Anonymous im Forum Sonstige Steuerungen
    Antworten: 2
    Letzter Beitrag: 22.01.2006, 15:08

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •