Communication directly via TCP (without using HTTP)

Jonzy

Hi,
I am using the Duet 2 Ethernet. Does the board provide a direct TCP connection to bypass HTTP ?

Many thanks.
Jonzy

You can enable the telnet protocol and send Gcode directly to it if thats what you're after?

See https://duet3d.dozuki.com/Wiki/Gcode#Section_M586_Configure_network_protocols for how to enable telnet.

Danal

Saying "Direct TCP" doesn't say anything.

What do you want the payload inside the TCP packet to look like? ASCII characters? That are interpreted as what? Gcode? If so, then @bearer suggestion above to enable Telnet is the answer. But that's not "Direct TCP", that's "Telnet".

Also, are you running firmware V2 or V3? Telnet works on both with the hardware you specified: Duet 2 Ethernet. But, for other people reading this thread, telnet changed with hardware configurations that include a Pi, and would not work as described.

Tell us more about what you are doing, and we will try to find a way.

Jonzy

Thank you for the replies.

Telnet/SSH is no longer up to date but i guess it's faster than HTTP.
What I hoped for was a connection like with a server (Get connected with IP and PORT)

I make some tests about the communication time and wil inform you about my results.

@Jonzy said in Communication directly via TCP (without using HTTP):

Telnet/SSH is no longer up to date but i guess it's faster than HTTP.
What I hoped for was a connection like with a server (Get connected with IP and PORT)

? without a password set for the duet, the "telnet" option for the Duet is just a socket that feeds gcode into the duet's queue; unlike what you've been lead to believe there is none of the features telnet would offer a terminal.

But the http server is also just an IP and a port, the port just happens to be 80. What is it you're trying to achieve?

Danal

@Jonzy said in Communication directly via TCP (without using HTTP):

Thank you for the replies.

Telnet/SSH is no longer up to date but i guess it's faster than HTTP.

Telnet. Duet does not support SSH.

And you are correct, telnet is horribly out of date, and completely insecure. That is why it is disabled on Duet unless you specifically enable it.

Also "faster" (whatever that means) really doesn't enter into selecting one or the other. They are completely different use cases for Duet printers. On a Telnet connection, all payload in the stream will be interpreted as G-Code lines. The HTTP connections allow queries of printer status, finding current coordinates, things like that.

What I hoped for was a connection like with a server (Get connected with IP and PORT)

To be pedantic, IP does not have the concept of a port. Only TCP, UDP, and other higher level protocols that ride on IP have ports.

Setting pedantry aside, both Telnet and HTTP are TCP/IP connections. Telnet to port 22 and HTTP to port 80.

But, again, the protocol is not the key here... it is the way that Duet Firmware interacts with each. Telnet=gcode, HTTP=full management of the printer.

And, again, please tell us what you are trying to do, and we will try to help.

Danal

Also, just to be REALLY pedantic about it, minimal HTTP header is 10 bytes. TCP itself adds 20 header bytes to every IP packet. So if you are concerned about "faster", better go UDP.

Jonzy

It's about the performance of the Board and not about the physical data transportation. I want to skip the iterpreter in HTTP.

I measured the duration of 500 status commands with Telnet and HTTP, 20 times each.
The mean results are
HTTP: 176 ms (Min.: 177, Max.: 205)
Telnet: 154 ms (Min.: 158, Max.: 178)

The difference is less than I expected.

For me, the topic is settled. Thank you for the quick answeres.

If you're concerned about latency you might want to look into websockets instead of vanilla http.

Jonzy

Oh no I'm so sorry - I did a big mistake in the time measurement.

The time to transfer 500 status cmds are:
HTTP: 5650 ms / 500 = 11,3 ms per status cmd
Telnet: 3453 ms / 500 = 6,9 ms per status cmd

This is a very high difference!

If you elaborate on what you want to achieve instead of how you want to achieve it you may get some more relevant input, as well as some validation perhaprs.

Coffee

Are you wanting to configure a connection so the Duet can act like/as a network/workgroup drive/resource? Like for drag and drop file movement?

Danal

The things you can do with those two connections are entirely different.

For instance, what is the timing of querying whether the printer is "Idle" or "Processing" or "Paused"? Or what coordinate system the printer is currently using? Or the currently mounted tool? There are literally hundreds of other examples.

There is no effective way to do any of those things via Telnet. They are all in the JSON returned by HTTP queries.

And, to @bearer 's point, V3 of the firmware supports websockets. Very low overhead, very fast. Also returns JSON.

And, for the third or fourth time, please tell us what you are trying to achieve and we will do our best help.

Please note that (other than my smart-alec comment about UDP), I have not discussed any overhead/performance numbers or timings. Why? That discussion is moot. A printer running Duet/Reprap firmware can be managed by HTTP and/or Websockets. Not by telnet.

@Danal said in Communication directly via TCP (without using HTTP):

There is no effective way to do any of those things via Telnet. They are all in the JSON returned by HTTP queries.

isn't that json stuff available as f.ex. M408 S2 regardless of the interface used?

@Coffee said in Communication directly via TCP (without using HTTP):

Are you wanting to configure a connection so the Duet can act like/as a network/workgroup drive/resource? Like for drag and drop file movement?

unlikely, but the limited ftp support would be a better approach than rigging something using g-code.

Danal

@bearer said in Communication directly via TCP (without using HTTP):

@Danal said in Communication directly via TCP (without using HTTP):

There is no effective way to do any of those things via Telnet. They are all in the JSON returned by HTTP queries.

isn't that json stuff available as f.ex. M408 S2 regardless of the interface used?

Actually, yes. Good point. I stand corrected, the JSON is available.

BUT... rr_download?name=XXX, rr_upload?name=XXX, and several other similar commands have no G-Code equivalent. The require a multi-packet stream, and there is no framework for that on Telnet or in G-Code. So the point that the printer can be fully managed with HTTP/Websockets, and not via Telnet, that point stands.

Jonzy

For me, the Duet Board is not a "3D prtinter board", it is a very gerat stepper driver board. I do not want to use the board to control a printer.
For control tasks I need as high a performance as possible and a dead time through communication is very bad. That's why I asked about another communication instead of HTTP.

I will program a Telnet interface for my task. According to my measurements, it's twice as fast.

Danal

You said:

The time to transfer 500 status cmds are:
HTTP: 5650 ms / 500 = 11,3 ms per status cmd
Telnet: 3453 ms / 500 = 6,9 ms per status cmd

11.3-6.9 = 4.4 Milliseconds.

Please be aware that G-Code commands do NOT get executed immediately by the board. They go into an input queue for a motion planner. That planner schedules execution according to what came before, and what the machine is doing. For example, the startup of a move will have VERY different timing depending on the angle of that move vs the 'prior' (really, currently running) move.

Also, the motion planner "looks ahead" to optimize sequences of moves. If it can't get the 'next' moves to look at, it will sometimes wait for them as existing moves in the queue complete.

4ms +/- of packet overhead is trivia compared to all the things that vary on a motion planner board. Duet or anything else that has a planner.

If you are thinking about "send this gcode and the motors move" with consistent, very low, latency, like a driver board, then planner boards (of any type or manufacturer) do not really fit that use case. There are driver boards that are designed to do this, respond in a consistent and real time fashion. And/or a custom solution could be easily coded in this day and age of $4 or $5 USD multi-core screamingly fast single-board computers. (ESP32 comes to mind)

Speaking of which, can you tell us anything more about the use case?

klipper uses the serial interface, might be more reliable.

charames

@Danal Slight correction... telnet is port 23 (22 is SSH).

@charames true, but, https://forum.duet3d.com/post/158859

charames

@bearer Yikes. didn't know... just joined today.

Phaedrux

I'm sure he would have appreciated the attention to detail.

@charames no worries, just don't be surprised when there isn't a reply..

charames

I was led to this thread while looking for information on issues related to network latency. It seems Duet is known to have frequent connection drop issues, but most of those threads seem to zone in on WiFi as the culprit. However, I am using a Maestro on a wired link and experience connection drops if I connect over the internet (as opposed to locally on my network). Conclusion: latency seems to play a role. Mine was suitably functional after I played around with the "communication settings" (update interval=800mS). But, then I updated the UI to version 2.0.7 and started seeing disconnects again (this time with a message: “Connection interrupted, attempting to reconnect”). I have tried adjusting the Communication Settings since that worked for version 1.22.6, but no values that I have tried have made it any better. It still works well when connected locally, but the additional latency of the internet makes the connection unusable.

I can click on the “Revert to DWC1” link and it suddenly works again. My conclusion is that there is something about the 2.0.7 build that is even more latency sensitive than DWC1 was.

I know this isn't the right thread for this discussion, but "latency" is what brought me here. I'll continue searching.