Possible to send binary data with M559 over Telnet?

Phaedrux

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

Otso

@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)

Phaedrux

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.

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.

Otso

@otso Now upgraded to 3.4 and the issue persists.

Otso

@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.

Phaedrux

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

Otso

@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.

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.

Phaedrux

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

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.

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.

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

chrishamm

@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.