Is there a way to get the measured/calculated value that the probing came up with?
The documentation says, “probing is repeated until two consecutive probe attempts produce results that differ by no more than the S parameter; then the average of those two results is used. However, if the number of attempts specified by the A parameter is reached without getting two consecutive results within tolerance of each other, no further probe attempts are made and the average result of all the attempts is used.”
I would like to be able to get the value that is being used (especially after a failure to get 2 consecutive ones in a sequence of nnn attempts).

oh, right... I do realize that I can get the average of 2 successful back-to-back probes by reading the heightmap.csv, but that won't tell me what value I have just measured as result of a home-z, for example. I want to be able to do some programmatic analysis before I allow a job to kick off using the measurement/calculation that the home command just came up with.

Is there a way to get the measured/calculated value that the probing came up with?
The documentation says, “probing is repeated until two consecutive probe attempts produce results that differ by no more than the S parameter; then the average of those two results is used. However, if the number of attempts specified by the A parameter is reached without getting two consecutive results within tolerance of each other, no further probe attempts are made and the average result of all the attempts is used.”
I would like to be able to get the value that is being used (especially after a failure to get 2 consecutive ones in a sequence of nnn attempts).

@Phaedrux Ah, thanks. Your question helped me solve it. For some reason my printer manufacturer chose not to follow the recommendation in the Duet documentation whereby it is stated “our intention is that in a 3D printer with a single print head, you use the Fan0 output for the print cooling fan and the Fan1 output for the heatsink fan. This is the easiest configuration to use because it's what the firmware expects by default." Rather, they wired the part cooling fan up to Fan1 and the tool fan up to Fan0. In any case, I swapped them in the M950/M106 config commands and it works, now. The only thing that is mysterious to me is why it worked previously when I explicitly provided P0 in the M106 command.

In RRF3.3.1, "M106 S80" does not result in turning on the part fan like it did in 2.x, but "M106 P0 S80" does. Conclusion: the default P0 is not being properly applied in RR3.1.1. Consequently, gcode code control over part cooling is not working as the slicer sends M106 Sxx to turn on the part cooling fan (with an implied P0). Here is the config:
M950 F0 C"fan1" Q50
M106 P0 H-1 X255
Did I miss something?

@Phaedrux You, too... thanks.

@bearer Thanks. I think I'll take the leap.

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

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.

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

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