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

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 22

Thema: Libnodave getXXXfrom()

  1. #11
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Red-Sh4nks Beitrag anzeigen
    DINT ist doch Double Int.
    Int ist 32 Bit lang
    DINT wäre dann 64 Bit lang.

    Falls das bis hier nicht stimmt, ignorier bitte folgendes:

    Du kannst das Ergebnis doch auch aus dem Puffer lesen
    und ihn den gewünschten Datentyp konvertieren.

    angenommen:

    dc.davereadbytes(libnodave.davedb, 1, 0, 4, Puffer)
    Puffer muss halt ein Array von der Mindestgröße 4 sein.

    dannach:
    convert.toint64(Puffer[0])

    und schon hast du den Inhalt des Datenblocks 1 an der Stelle
    0 gelesen und in den Datentyp DoubleInt konvertiert.

    GetS32 ist daher überflüssig. Ich verwende es bei meinem Programm nicht.
    Ich konvertiere das gelesene direkt in aus dem Lesepuffer in den gewünschten Datentyp

    lg Marco*
    in s7 ist ein dint 32 bit und ein normaler int 16 bit (die größe eines int's ist nicht vorgeschrieben, das ist architektur und programmiersprachen abbhänig!)

    und was bringt dein convert?? da habe ich ein byte in ein int64 verwandelt! aber wenn er doch einen dint von der sps lesen will muss er ja 4 bytes gemeinsam umtauschen!
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten

  2. #12
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Zitat Zitat von Jochen Kühner Beitrag anzeigen
    in s7 ist ein dint 32 bit und ein normaler int 16 bit (die größe eines int's ist nicht vorgeschrieben, das ist architektur und programmiersprachen abbhänig!)

    und was bringt dein convert?? da habe ich ein byte in ein int64 verwandelt! aber wenn er doch einen dint von der sps lesen will muss er ja 4 bytes gemeinsam umtauschen!
    und da libnodave ja auch unter mono auf einer anderen plattform laufen könnte musser beim umtauschen auch noch die bytereihenfolge (Endianes) beachten!
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten

  3. #13
    Registriert seit
    13.01.2010
    Beiträge
    40
    Danke
    21
    Erhielt 0 Danke für 0 Beiträge

    Standard

    aber wenn er doch einen dint von der sps lesen will muss er ja 4 bytes gemeinsam umtauschen!
    hmmm... Hast recht. Aber dass kann ja nicht so schwer sein.
    "Dem sind keine Grenzen gesetzt, der sie nicht hinnimmt!"

  4. #14
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Zitat Zitat von Red-Sh4nks Beitrag anzeigen
    hmmm... Hast recht. Aber dass kann ja nicht so schwer sein.

    Nei ist ja auch nicht, deswegen gibt es die getS32From usw...
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten

  5. #15
    Registriert seit
    26.03.2010
    Beiträge
    94
    Danke
    3
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo habe das Problem grade in der anderen Richtung (schreiben, statt lesen) bei meinem VB.NET Proggi. Die die Funktionen libnodave.putU32() und libnodave.putS32() verursachen beim Ausführen eine Speicherbereichsverletzung "Der Index war außerhalb des Arraybereichs.". Ist dies hier wie von Zottel argumentiert in der Pointer Problematik von .NET begründet oder hat dies eine andere Ursache?
    Hab das Problem nun folgendermassen gelöst, doch wollte ich verstehen weshalb es zu diesem Fehler kommt.

    Problemcode:
    Public testbuffer(220) AsByte
    ...
    libnodave.putU32at(testbuffer, 0, intValue)
    ...

    So gehts nun:
    Case"DWord"
    tempBuffer = BitConverter.GetBytes(intValue)
    Buffer(0) = tempBuffer(3)
    Buffer(1) = tempBuffer(2)
    Buffer(2) = tempBuffer(1)
    Buffer(3) = tempBuffer(0)
    'libnodave.putU32at(testbuffer, 0, intValue)
    res = dc.writeBytes(nArea, nDBnr, nByteAdr, nDataLength, Buffer)

    Zusatzfrage: gibt es eigentlich auch eine Funktion libnodave.putU8() oder s.ä. oder wurde darauf verzichtet, da es sich nur um ein Byte handelt und sich die Byteausrichtung der CPU etc. hier nicht drauf auswirkt, bzw der Datentyp "Byte" ohnehin vozeichenlos ist?

    Gruss,

    bool

  6. #16
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Zitat Zitat von bool Beitrag anzeigen
    Hallo habe das Problem grade in der anderen Richtung (schreiben, statt lesen) bei meinem VB.NET Proggi. Die die Funktionen libnodave.putU32() und libnodave.putS32() verursachen beim Ausführen eine Speicherbereichsverletzung "Der Index war außerhalb des Arraybereichs.". Ist dies hier wie von Zottel argumentiert in der Pointer Problematik von .NET begründet oder hat dies eine andere Ursache?
    Hab das Problem nun folgendermassen gelöst, doch wollte ich verstehen weshalb es zu diesem Fehler kommt.

    Problemcode:
    Public testbuffer(220) AsByte
    ...
    libnodave.putU32at(testbuffer, 0, intValue)
    ...

    So gehts nun:
    Case"DWord"
    tempBuffer = BitConverter.GetBytes(intValue)
    Buffer(0) = tempBuffer(3)
    Buffer(1) = tempBuffer(2)
    Buffer(2) = tempBuffer(1)
    Buffer(3) = tempBuffer(0)
    'libnodave.putU32at(testbuffer, 0, intValue)
    res = dc.writeBytes(nArea, nDBnr, nByteAdr, nDataLength, Buffer)

    Zusatzfrage: gibt es eigentlich auch eine Funktion libnodave.putU8() oder s.ä. oder wurde darauf verzichtet, da es sich nur um ein Byte handelt und sich die Byteausrichtung der CPU etc. hier nicht drauf auswirkt, bzw der Datentyp "Byte" ohnehin vozeichenlos ist?

    Gruss,

    bool
    Die putU32 at ist doch in der libnodave.net.dll fast genau so implementiert! Ich denke die mit nur einem Bytes gibt es nicht, da man ein byte einfach direkt in dem array zuweisen kann, bei den anderen funktionen muss halt wieder die endianess beachtet werden!
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten

  7. #17
    Registriert seit
    26.03.2010
    Beiträge
    94
    Danke
    3
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Zitat Zitat von Jochen Kühner Beitrag anzeigen
    Die putU32 at ist doch in der libnodave.net.dll fast genau so implementiert!
    ... und doch gibt es die Speicherverletzung ...


    Habe grad mal einen Blick in den Sourcecode der libnodave.net.dll gewagt und siehe da ...die Betonung liegt hier auf "fast":

    public static void putU32at(byte[] b, int pos, int value)
    {
    byte[] bytes = BitConverter.GetBytes(Convert.ToUInt32(value));
    if (BitConverter.IsLittleEndian)
    {
    b[pos + 3] = bytes[0];
    b[pos + 2] = bytes[1];
    b[pos + 1] = bytes[2];
    b[pos] = bytes[4];
    }
    else
    Array.Copy(bytes, 0, b, pos, 4);
    }

    Ich vermute das "bytes[4]" musste "bytes[3]" heissen oder liege ich hier falsch?

    Das selbe giltet übrigens auch für die Funktion "putS32at".

    Gruss,

    bool
    Geändert von bool (07.06.2010 um 00:50 Uhr)

  8. #18
    Registriert seit
    26.03.2010
    Beiträge
    94
    Danke
    3
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Zitat Zitat von bool Beitrag anzeigen

    Ich vermute das "bytes[4]" musste "bytes[3]" heissen oder liege ich hier falsch?

    Das selbe giltet übrigens auch für die Funktion "putS32at".
    scheint wohl tatsächlich "bytes[3]" heissen zu müssen. Habs grad in der cs geändert und neu compiliert, jetzt gehts auch ohne Speicherverletzung

    Gruss,

    bool

  9. #19
    Registriert seit
    26.03.2010
    Beiträge
    94
    Danke
    3
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Habe da noch ein weiteres Problem festgestellt.

    Wenn die Fuktion "putS16at" aufgerufen wird und ein Wert >32767 übergeben wird, gibt es ein exeption error, da angeblich durch "0" geteilt wird ebenso bei Verwendng eine negativen Zahl in Verbindung mit der Funktion "putU16at".

    GGf. sollten die Funktionen soweit "gehärtet" werden, dass die exeptions vermieden werden können. Vielleicht würde es hier dann Sinn machen wenn über einen Rückgabewert ein Fehlercode (z.B. "-1" oder FALSE) übergeben wird.

    Die Frage wäre evtl. auch, ob die Konvertierung in INT16 bzw UINT16 vorab in den Funktionen nötig ist. Es werden ohnehin Funktionsintern nur die entsprechenden Bytes kopiert.

    Gruss,

    bool

  10. #20
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von bool Beitrag anzeigen
    Habe da noch ein weiteres Problem festgestellt.

    Wenn die Fuktion "putS16at" aufgerufen wird und ein Wert >32767 übergeben wird, gibt es ein exeption error, da angeblich durch "0" geteilt wird ebenso bei Verwendng eine negativen Zahl in Verbindung mit der Funktion "putU16at".

    GGf. sollten die Funktionen soweit "gehärtet" werden, dass die exeptions vermieden werden können. Vielleicht würde es hier dann Sinn machen wenn über einen Rückgabewert ein Fehlercode (z.B. "-1" oder FALSE) übergeben wird.

    Die Frage wäre evtl. auch, ob die Konvertierung in INT16 bzw UINT16 vorab in den Funktionen nötig ist. Es werden ohnehin Funktionsintern nur die entsprechenden Bytes kopiert.

    Gruss,

    bool
    Hab das nun auch geändert, und die 16 Bit Funktionen so angepasst das sie einen short oder ushort zurückgeben oder erwarten. Ich denke, den Funktionen sollte auch nur der Datentyp übergeben werden, den Sie handeln können!
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten

Ähnliche Themen

  1. Antworten: 0
    Letzter Beitrag: 09.09.2010, 00:27
  2. ÄÖnderungen am libnodave.net.cs File von libnodave
    Von Jochen Kühner im Forum Hochsprachen - OPC
    Antworten: 5
    Letzter Beitrag: 12.05.2010, 16:56
  3. LibNoDave unter VB.Net ohne libnodave.net.dll
    Von Earny im Forum Hochsprachen - OPC
    Antworten: 2
    Letzter Beitrag: 09.03.2010, 18:57
  4. libnodave: Woher kommt die "libnodave.net.dll"?
    Von Thomas_v2.1 im Forum Hochsprachen - OPC
    Antworten: 2
    Letzter Beitrag: 10.11.2008, 12:07
  5. Libnodave - VB
    Von shuemmer im Forum Hochsprachen - OPC
    Antworten: 0
    Letzter Beitrag: 07.07.2006, 18:57

Lesezeichen

Berechtigungen

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