No announcement yet.

BUG: PACKETIN - Max number of bytes to read from packet

  • Filter
  • Time
  • Show
Clear All
new posts

  • BUG: PACKETIN - Max number of bytes to read from packet

    EDIT: Appears to only affect the simulator, works as expected on H2-DM1E.

    According to the documentation: "Max Number of Bytes to read from Packet - Specified the number of bytes to copy from the Packet Device to the Input to String location. This can be any readable numeric location or any constant value from 1 to 1024. If the value specified is smaller than the number of bytes actually in the buffer, only the specified number of bytes will be copied to the Input to String location, any remaining bytes will be discarded."

    If I send a packet greater than this number(even by a single byte), and the data destination is a string struct, then the string is empty when the packetin completes. If the data destination is a byte buffer, then the buffer does indeed get filled with the data of the new packet, up to the correct number of bytes; _However_ The 'Number of Bytes Read' returns 0.

    It's my opinion that the string case should fill with the packet data up to the max number of bytes, and that the 'Number of Bytes Read' should return the correct amount(basically equal the specified max) in the byte buffer case.

    Note: I have not tested this on hardware, this is using the simulator. My software version is 2.1.4.
    To reproduce, you can paste this into a new simulator project.
    For some reason although it creates all the needed memory for the paste, the contact doesn't paste correctly and needs to be re-set to '$RcvSocket.PacketAvailable'. You can switch between string and byte buffer data destinations easily. Finally, send it < 8 bytes via udp, then more to see the erroneous behavior.
    Ohh, and the udp device is set to port 5000.

    Last edited by Sci; 02-02-2018, 04:18 PM.

  • #2
    It's probably filling the buffer in both cases, but since the length field defines the content of a string, it just looks like it didn't. And yes, I agree that the actual count should be updated. Should be an easy fix.


    • #3
      Perhaps it's broken in the simulator, but it is working as expected in hardware. There is one curious quirk I can't explain yet: it's either refusing to send a packet greater than 1492 bytes or is refusing to receive it. But anything 1492 or less is working as expected, and does copy the first n bytes as documented.


      • #4
        Brain cramp...1492 is the maximum payload after accounting for UDP overhead. So the Sim could be broken due to differences in the IP stack (entirely possible), but the hardware implementation appears to be working correctly, which means most of the Sim code is correct as well.


        • #5
          Just loaded it onto a H2-DM1E, and can confirm everything works as expected/intended there. Updated my top post to reflect. Seems like it's only a simulator bug.


          • #6
            Fixed. Windows stack does what you want, but treats it as an error.


            • #7
              On the rare chance that anyone runs into this issue before a patch is available; It's unlikely(impossible?) to be receiving udp packets of 0 size; So for now I just have a rung that runs if $PLCType is Simulator(1) and readLength = 0, and re-sets the read-length to whatever the max used in the PACKETIN was. This works when using the byte buffer version. String version would still be an issue.

              Thanks for looking in to it guys!