Problem: Fluidnc seems to respond to a jog command with the jog command itself on additional uart
leogala opened this issue · comments
Wiki Search Terms
jog, $J
Controller Board
6-pack
Machine Description
Omio X6
Input Circuits
No response
Configuration file
board: 6 Pack
name: 6 Pack External XYZABC PWM
meta: 2023-01-29 B. Dring
uart1:
txd_pin: gpio.23
rxd_pin: gpio.19
baud: 115200
mode: 8N1
uart_channel1:
uart_num: 1
stepping:
engine: I2S_STREAM
idle_ms: 255
pulse_us: 4
dir_delay_us: 1
disable_delay_us: 0
axes:
shared_stepper_disable_pin: NO_PIN
x:
steps_per_mm: 320.000
max_rate_mm_per_min: 4000.000
acceleration_mm_per_sec2: 300.000
max_travel_mm: 300.000
soft_limits: false
homing:
cycle: 2
positive_direction: true
mpos_mm: 0.000
feed_mm_per_min: 100.000
seek_mm_per_min: 200.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.32:low
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
standard_stepper:
step_pin: I2SO.2:low
direction_pin: I2SO.1
disable_pin: I2SO.0:low
y:
steps_per_mm: 320.000
max_rate_mm_per_min: 4000.000
acceleration_mm_per_sec2: 300.000
max_travel_mm: 300.000
soft_limits: false
homing:
cycle: 3
positive_direction: false
mpos_mm: 0.000
feed_mm_per_min: 100.000
seek_mm_per_min: 200.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.34:low
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
standard_stepper:
step_pin: I2SO.5:low
direction_pin: I2SO.4:low
disable_pin: I2SO.7:low
z:
steps_per_mm: 320.000
max_rate_mm_per_min: 1000.000
acceleration_mm_per_sec2: 150.000
max_travel_mm: 150.000
soft_limits: false
homing:
cycle: 1
positive_direction: true
mpos_mm: 150.000
feed_mm_per_min: 100.000
seek_mm_per_min: 800.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.35:low
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
standard_stepper:
step_pin: I2SO.10:low
direction_pin: I2SO.9:low
disable_pin: I2SO.8:low
a:
steps_per_mm: 13.333
max_rate_mm_per_min: 500.000
acceleration_mm_per_sec2: 200.000
max_travel_mm: 150.000
soft_limits: false
homing:
cycle: 1
positive_direction: true
mpos_mm: 150.000
feed_mm_per_min: 100.000
seek_mm_per_min: 800.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.33:low
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
standard_stepper:
step_pin: I2SO.13:low
direction_pin: I2SO.12:low
disable_pin: I2SO.15:low
b:
steps_per_mm: 100.000
max_rate_mm_per_min: 5000.000
acceleration_mm_per_sec2: 100.000
max_travel_mm: 150.000
soft_limits: false
homing:
cycle: 1
positive_direction: true
mpos_mm: 150.000
feed_mm_per_min: 100.000
seek_mm_per_min: 800.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: NO_PIN
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
standard_stepper:
step_pin: I2SO.18
direction_pin: I2SO.17
disable_pin: I2SO.16:low
c:
steps_per_mm: 100.000
max_rate_mm_per_min: 5000.000
acceleration_mm_per_sec2: 100.000
max_travel_mm: 150.000
soft_limits: false
homing:
cycle: 1
positive_direction: true
mpos_mm: 150.000
feed_mm_per_min: 100.000
seek_mm_per_min: 800.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: NO_PIN
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
standard_stepper:
step_pin: I2SO.21
direction_pin: I2SO.20
disable_pin: I2SO.23:low
probe:
pin: gpio.36:low
check_mode_start: true
i2so:
bck_pin: gpio.22
data_pin: gpio.21
ws_pin: gpio.17
start:
must_home: false
PWM:
pwm_hz: 5000
output_pin: gpio.25
enable_pin: gpio.2
direction_pin: NO_PIN
disable_with_s0: false
s0_with_disable: true
spinup_ms: 5
spindown_ms: 3
tool_num: 0
speed_map: 0=0% 10000=100%Startup Messages
$ss
[MSG:INFO: FluidNC 3.7.13 https://github.com/bdring/FluidNC]]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]]
[MSG:INFO: Local filesystem type is littlefs]]
[MSG:INFO: Configuration file:config.yaml]]
[MSG:INFO: Machine 6 Pack External XYZABC PWM]]
[MSG:INFO: Board 6 Pack]]
[MSG:INFO: UART1 Tx:gpio.23 Rx:gpio.19 RTS:NO_PIN Baud:115200]]
[MSG:INFO: uart_channel1 created]]
[MSG:INFO: standard_stepper Step:I2SO.5:low Dir:I2SO.4:low Disable:I2SO.7:low]]
[MSG:INFO: Y Neg Limit gpio.34:low]]
[MSG:INFO: Motor0]]
[MSG:INFO: standard_stepper Step:I2SO.13:low Dir:I2SO.12:low Disable:I2SO.15:low]]
[MSG:INFO: A Neg Limit gpio.33:low]]
[MSG:INFO: Axis B (0.000,150.000)]]
[MSG:INFO: Motor0]]
[MSG:INFO: standard_stepper Step:I2SO.18 Dir:I2SO.17 Disable:I2SO.16:low]]
[MSG:INFO: Axis C (0.000,150.000)]]
[MSG:INFO: Motor0]]
User Interface Software
No response
What happened?
I have a problem with jogging, which is probably related to my mistake, but I am observing a strange behaviour of Fluidnc.
I am building a pendant with an extra serial uart configured without report_interval_ms, because auto report does not seem to report feed OV changes, ie:
uart1:
txd_pin: gpio.23
rxd_pin: gpio.19
baud: 115200
Mode: 8N1
uart_channel1:
uart_num: 1
Normally I send jog commands and get an ok response, for example
Sent
$J=G91 X0.153 Y0.000 Z0.000 F92.000
Reply
ok
that's fine.
However, under certain conditions that I don't know yet, for example if I reset the esp32 used in the pendant without resetting fluidnc, when I send a jog command fluidnc seems to respond by repeating my jog command. For example
Sent
$J=G91 X0.153 Y0.000 Z0.000 F92.000
Reply
$J=G91 X0.153 Y0.000 Z0.000 F92.000
ok
When I restart fluidnc, without touching my pendant, everything goes back to normal and fluidnc just replies with an ok.
Even if this does not affect functionality, it is redundant traffic that I would like to avoid.
So my question is:
Is there a way to force fluidnc to respond to a jog command by repeating the jog command?
GCode File
No response
Other Information
No response
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.
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
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.
@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.
Is there a command do disable this echo mode that I could send when the pendant starts ?
I guess you didn't read the link that @breiler provided.