Communication directly via TCP (without using HTTP)
-
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?
-
@Phaedrux said in Communication directly via TCP (without using HTTP):
RRF 3.1.1 and DWC 3.1.1
I'll look into that, but I was under the impression that those updates introduced some significant changes that would require that I re-do all of my configs. Maybe its worth doing, but since I ONLY have connection issues as a complaint, I was looking for a solution for that.
-
@charames said in Communication directly via TCP (without using HTTP):
hose updates introduced some significant changes that would require that I re-do all of my configs.
yes-ish but now that 3.1.1 is seemingly stable it'll probably be worth while.
-
https://configtool.reprapfirmware.org/Start
The configuration tool has support for 3.1.1 now so getting a compatible basic config isn't as complicated as it once was. If you have some more complex features implemented you'd still have to do that manually, but it's generally just some minor syntax changes. The gcode wiki is your friend here. https://duet3d.dozuki.com/Wiki/Gcode
-
@bearer Thanks. I think I'll take the leap.
-
@Phaedrux You, too... thanks.
-
undefined magnets99 referenced this topic
