Problem: Fluidnc seems to respond to a jog command with the jog command itself on additional uart about fluidnc HOT 7 CLOSED

I set $Report/Interval=100 and it reports feed override every tenth report or immediately after any change to the override.

<Run|WPos:34.004,-0.000,0.000|Bf:14,128|FS:104,0>
<Run|WPos:33.834,-0.000,0.000|Bf:14,128|FS:104,0|Ov:104,100,100>
<Run|WPos:33.661,0.001,0.000|Bf:14,128|FS:104,0>
<Run|WPos:33.490,0.000,0.000|Bf:14,128|FS:104,0|WCO:0.000,0.000,0.000>
f<Run|WPos:33.317,-0.000,0.000|Bf:14,128|FS:104,0>
<Run|WPos:33.146,-0.000,0.000|Bf:14,128|FS:104,0>
<Run|WPos:32.973,0.001,0.000|Bf:14,128|FS:104,0>
<Run|WPos:32.803,0.000,0.000|Bf:14,128|FS:104,0>
<Run|WPos:32.629,-0.000,0.000|Bf:14,128|FS:104,0>
<Run|WPos:32.459,-0.000,0.000|Bf:14,128|FS:104,0>
<Run|WPos:32.286,0.001,0.000|Bf:14,128|FS:104,0>
<Run|WPos:32.115,0.000,0.000|Bf:14,128|FS:104,0|Ov:104,100,100>
- <FeedOvrFineMinus>
<Run|WPos:31.942,-0.000,0.000|Bf:14,128|FS:103,0|Ov:103,100,100>
<Run|WPos:31.772,-0.000,0.000|Bf:14,128|FS:103,0|WCO:0.000,0.000,0.000>

It does not report the new value after a feed change in idle until the next report. It does not force a new report. I suppose that could be added.

I have never seen FluidNC echo a command like that on uart1.

from fluidnc.

Could possible the local echo gotten activated, for instance if a FluidTerm was started?
http://wiki.fluidnc.com/en/features/serial_terminals#advanced-terminal-mode

from fluidnc.

The pendant work has exposed numerous problems with the Grbl serial line protocol. We have known about many of the problems for a long time, but have not had the opportunity to address them fully. I am going to write a page describing the problems in detail and explore some options for fixing them.

Meanwhile, people who are writing their own pendants and other serial UIs should treat the UART channel behavior as a work in progress. It is known to have problems, is subject to change, and should not be considered stable enough to be relied upon. We might not fix specific problem situations immediately. Instead I hope to develop a comprehensive and robust solution.

It is possible that our adherence to the release early, release often mantra is coming back to haunt us. We are now being overwhelmed with support requests from people trying to use the pendant code in different ways, often without the expertise to solve problems by themselves. That is draining our time.

from fluidnc.

@breiler could be correct. A serial channel will switch to echo mode if it receives an "editing character", for example a backspace, tab, or one of several other control characters that humans use to edit lines they are preparing. The pendant might not have sent such a character explicitly, but startup glitches on the serial line could be misinterpreted as a control character or as a realtime character, thus kicking FluidNC into an unintended mode. This is one of those problem situations I alluded to above.

from fluidnc.

Is there a command do disable this echo mode that I could send when the pendant starts ?

from fluidnc.

I guess you didn't read the link that @breiler provided.

from fluidnc.

In fact, I had completely overlooked this page. Following @breiler suggestion, the problem has been solved by sending 0xc (Ctrl-L) at pendant boot time. Thanks for your help.

from fluidnc.