Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Possible to send binary data with M559 over Telnet?

    Scheduled Pinned Locked Moved Unsolved
    General Discussion
    4
    18
    990
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Otsoundefined
      Otso
      last edited by Otso

      I'm continuing with my desktop app that communicates over Telnet. I'm now implementing file upload and using M559 P"filename" Snnn to upload files as binary. I'm not able to get it to work as expected. I must send much more data than provided in the S parameter before the Duet 2 Wifi thinks it has received all bytes. I tried sending just a few bytes at a time at a slow pace, but that didn't help. A quick look at the RepRapFirmware source code seems to indicate it always reads a line at time.

      For example, if I send the same 100 byte file, but one ending in a newline char, and the other not (and instead ending in, say, the character 'A'), then only the file ending in the newline char will be uploaded. So it seems to be relying on processing a line at time and gets mixed up in the byte counting.

      Is M559 P"filename" Snnn over Telnet supposed to work (with arbitrary binary content)?

      Otsoundefined chrishammundefined 2 Replies Last reply Reply Quote 0
      • Otsoundefined
        Otso @Otso
        last edited by Otso

        @otso I'm pretty sure this is a bug. How to repeat:

        • Create file1.txt with contents "012345678\n" (file size 10 bytes)
        • Create file2.txt with contents "0123456789" (file size 10 bytes)
        • Send M559 P"file1.txt" S10
        • Transmit the 10 bytes of file1.txt
        • File is successfully uploaded
        • Send M559 P"file2.txt" S10
        • Transmit the 10 bytes of file2.txt
        • The Duet2 with RepRapFirmware 3 waits for more input
        • You have to transmit more data after this, until it is accepted. A single newline is not enough.

        I have verified that the 10 bytes are actually transmitted and acknowledged on the TCP level by dumping the communication with tcpdump. So it's not that the data is buffered by the transmitter.

        Some more testing:

        • Transmit "0123456789" (10 bytes, no newline). All 10 bytes are sent in a single TCP packet, and acknowledged by the Duet.
        • Duet2 waits for more data
        • Transmit "54321\n" (6 bytes in a single TCP packet)
        • Duet wait for more data
        • Transmit 54321\n" (6 bytes in a single TCP packet)
        • File is saved. (and "1" is interpreted as a command)
        • Contents of the file is "54321\n5432" (10 bytes)

        So the first 10 bytes are completely discarded, and only the 10 following bytes are saved.

        1 Reply Last reply Reply Quote 0
        • Phaedruxundefined
          Phaedrux Moderator
          last edited by

          Firmware version?

          Z-Bot CoreXY Build | Thingiverse Profile

          Otsoundefined 1 Reply Last reply Reply Quote 0
          • Otsoundefined
            Otso @Phaedrux
            last edited by

            @phaedrux FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.3 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-06-15 21:45:03

            1 Reply Last reply Reply Quote 0
            • Phaedruxundefined
              Phaedrux Moderator
              last edited by

              Can I ask that you test with the 3.4 final firmware release?

              Z-Bot CoreXY Build | Thingiverse Profile

              Otsoundefined 1 Reply Last reply Reply Quote 0
              • Otsoundefined
                Otso @Phaedrux
                last edited by

                @phaedrux Sure. I'll have to read in a bit on how to do it first, since previously I've just followed the instructions provided by Ooznest without actually knowing what I've been doing. 🙂 (https://learn.ooznest.co.uk/Guide/How+To+Update+WorkBee+Firmware+V1.0.7+>+V3.3.0-1.2/240)

                1 Reply Last reply Reply Quote 0
                • Phaedruxundefined
                  Phaedrux Moderator
                  last edited by

                  It's as easy as uploading the zip file for the 3.4 release to the system tab in DWC.

                  https://github.com/Duet3D/RepRapFirmware/releases/download/3.4.0/Duet2and3Firmware-3.4.0.zip

                  Don't extract it first. It will take care of the rest.

                  Z-Bot CoreXY Build | Thingiverse Profile

                  Otsoundefined 1 Reply Last reply Reply Quote 0
                  • Otsoundefined
                    Otso @Phaedrux
                    last edited by Otso

                    @phaedrux Thanks! I was just reading that, but slightly hesitating since Ooznest has made a customized DWC for the WorkBee CNC (optimized for CNC operation rather than 3D printing). I guess I can just overwrite DWC later with the Ooznest version? Not that it is that important anymore since I now mainly use my own desktop app anyway, and not DWC. (Currently I mainly need DWC to upload my G-code files 😉 )

                    Edit: The DWC differences between the default and Ooznest version is minor, smaller than I remembered. It makes no practical difference, so there's no need for me to replace the default standard version with the Ooznest version.

                    Otsoundefined 1 Reply Last reply Reply Quote 0
                    • Otsoundefined
                      Otso @Otso
                      last edited by

                      @otso Now upgraded to 3.4 and the issue persists.

                      Otsoundefined 1 Reply Last reply Reply Quote 0
                      • Otsoundefined
                        Otso @Otso
                        last edited by

                        @otso But I might as well implement the file upload using HTTP, since I realized there isn't any way to download files over Telnet, right? (For example if you want to edit files). So I might do both file upload and download over HTTP, and then M559 will not be an issue for me.

                        1 Reply Last reply Reply Quote 0
                        • Phaedruxundefined
                          Phaedrux Moderator
                          last edited by

                          I can't imagine telnet being the preferred method for anything these days.

                          Z-Bot CoreXY Build | Thingiverse Profile

                          Otsoundefined 1 Reply Last reply Reply Quote 0
                          • Otsoundefined
                            Otso @Phaedrux
                            last edited by

                            @phaedrux I prefer Telnet in this case as it keeps the connection open and there is no overhead. Websockets would be an improvement (but still has unnecessary overhead). The "raw" connection of Telnet is nice and clean, and my app will work the same if connected over USB or serial.

                            Otsoundefined 1 Reply Last reply Reply Quote 0
                            • Otsoundefined
                              Otso @Otso
                              last edited by Otso

                              @Phaedrux I'm running in Marlin compatibility mode, if that makes a difference for the M559 issue.

                              Edit: Does not make a difference if I switch to RepRapFirmware mode.

                              1 Reply Last reply Reply Quote 0
                              • Phaedruxundefined
                                Phaedrux Moderator
                                last edited by

                                I'll see if DC42 can take a look at your telnet question.

                                Z-Bot CoreXY Build | Thingiverse Profile

                                Otsoundefined 2 Replies Last reply Reply Quote 1
                                • Otsoundefined
                                  Otso @Phaedrux
                                  last edited by Otso

                                  @phaedrux Thank you! Please keep it at as a low priority, unless you have a general interest in fixing it. It's not that important or critical for me. A note in the documentation would be helpful, however.

                                  1 Reply Last reply Reply Quote 0
                                  • Otsoundefined
                                    Otso @Phaedrux
                                    last edited by Otso

                                    @phaedrux With a quick test, sending with M559 without the Snnn parameter and instead terminating with M29 doesn't seem to work either:

                                    M559 P"/gcodes/foobar.txt"
                                    Writing to file: /gcodes/foobar.txt
                                    ok
                                    Hello
                                    World
                                    M29
                                    
                                    
                                    

                                    I would expect ok after M29. The only way I can continue is rebooting.

                                    1 Reply Last reply Reply Quote 0
                                    • OwenDundefined
                                      OwenD
                                      last edited by OwenD

                                      M559 is supposed to be terminated by sending M29
                                      I don't see that in your original test.
                                      On the one where it froze did you send a line feed before M29?
                                      Perhaps try again with the S parameter and M29

                                      You might also try M560
                                      It has a special EOF line

                                      1 Reply Last reply Reply Quote 0
                                      • chrishammundefined
                                        chrishamm administrators @Otso
                                        last edited by

                                        @otso The Telnet responder isn't designed to deal with binary file uploads. The reason is that Telnet data is processed line by line and if the line length exceeds the maximum length (255 chars), the line content is dropped and an error message is written to the USB line (if possible).

                                        So, at least for now, you should use the rr_upload HTTP request for binary data. I'll discuss with @dc42 how we will treat M559 from Telnet in the next RRF version.

                                        Duet software engineer

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post
                                        Unless otherwise noted, all forum content is licensed under CC-BY-SA