Communication directly via TCP (without using HTTP)
-
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.
-
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 cmdThis 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.
-
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?
-
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 S2regardless 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.
-
@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 S2regardless 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.
-
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.
-
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 cmd11.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.
-
@Danal Slight correction... telnet is port 23 (22 is SSH).
-
@charames true, but, https://forum.duet3d.com/post/158859
-
@bearer Yikes. didn't know... just joined today.
-
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..
-
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.
-
@charames said in Communication directly via TCP (without using HTTP):
Conclusion: latency seems to play a role.
interesting, poor wifi signal can also result in increased latency
-
@charames It may be worth upgrading to RRF 3.1.1 and DWC 3.1.1 to test with recent code. @chrishamm would be the one to understand/explain the latency thing I think?
