Closed wtfiAndrewNelson closed 9 months ago
I managed to reproduce the problem:
*** Connecting to tcp://192.168.1.10:23
*** Fetching device status
> ?
<Alarm|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>
>
ok
Other: ok
*** Fetching device firmware version
> $I
error:9
*** Expected a 'FluidNC 3.3.0' or later but got 'Unknown 0.0.0'
*** Could not establish connection with the controller
*** Connection closed
The error 9: GCode cannot be executed in lock or alarm state
is triggered even though the $I
command is not a gcode command. It only happens on the TCP channel, when using USB serial it works. So I am guessing that this is a FluidNC bug and I will file a bug report to that project.
Interesting. You think that it's the fluidnc even though UGS platform 2.0.13 connects to it just fine? To me that would indicate that something new in UGS 2.1.x is not working properly? No?
Yes, I believe that this is a bug in FluidNC.
I added a command for disabling FluidNCs "echo mode" which is used when connecting to the controller through a terminal (#2349). If echo mode is enabled on the controller when connecting with UGS the communication will fail.
The "echo mode" command is currently treated as a gcode command, but only when using a telnet connection.
The command is apparently not available on FluidNC when connecting through a TCP channel. So I have added a detection if echo mode is activated and if so try to disable it.
It is available in the latest nightly build: https://github.com/winder/Universal-G-Code-Sender#downloads
Just gave it a try and it works brilliantly!
Just tried this with the latest nightly, and I was unable to connect to FluidNC.
*** Connecting to tcp://192.168.0.224:23
*** Fetching device status
>
ok
*** Fetching device firmware version
*** Fetching device status codes
*** Fetching device state
*** Could not establish connection with the controller
*** Connection closed
This is with:
UI: github.com/MitchBradley/ESP3D-WEBUI@279b61e / FW: fluidnc v3.7.12
UGS:
Product Version: Universal Gcode Sender 20240102
Java: 17.0.8.1; OpenJDK 64-Bit Server VM 17.0.8.1+1
Runtime: OpenJDK Runtime Environment 17.0.8.1+1
System: Mac OS X version 12.7.1 running on x86_64; UTF-8; en_US (ugsplatform)
User directory: /Users/ian/Library/Application Support/ugsplatform
Cache directory: /Users/ian/Library/Caches/ugsplatform/var/cache
I can't reproduce this with the UGS nightly build 20240102 and fluidnc 3.7.12. Can you post your FluidNC configuration.
Here it is:
board: MKS TinyBee V1.0 XXYYZ
name:
kinematics:
Cartesian:
i2so:
bck_pin: gpio.25
data_pin: gpio.27
ws_pin: gpio.26
spi:
miso_pin: gpio.19
mosi_pin: gpio.23
sck_pin: gpio.18
sdcard:
cs_pin: gpio.5
# uses TH2 IO34 active low - MAKE SURE jumper J2 is set to SDDET!!!
card_detect_pin: gpio.34:low
stepping:
engine: I2S_STATIC
idle_ms: 255
pulse_us: 4
dir_delay_us: 1
disable_delay_us: 2
axes:
x:
steps_per_mm: 40
max_rate_mm_per_min: 8000.000
acceleration_mm_per_sec2: 80.000
max_travel_mm: 2500.000
soft_limits: false
homing:
cycle: 2
positive_direction: false
mpos_mm: 0.000
feed_mm_per_min: 300.000
seek_mm_per_min: 1500.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.33:low:pu
hard_limits: true
pulloff_mm: 4.000
standard_stepper:
step_pin: I2SO.1
direction_pin: I2SO.2
disable_pin: I2SO.0
# use E0 driver for 2nd X axis motor
motor1:
hard_limits: true
pulloff_mm: 4.000
standard_stepper:
step_pin: I2SO.10
direction_pin: I2SO.11
disable_pin: I2SO.9
y:
steps_per_mm: 40
max_rate_mm_per_min: 8000.000
acceleration_mm_per_sec2: 70.000
max_travel_mm: 1250.000
soft_limits: false
homing:
cycle: 3
positive_direction: false
mpos_mm: 0.000
feed_mm_per_min: 300.000
seek_mm_per_min: 2000.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.32:low:pu
hard_limits: false
pulloff_mm: 4.000
standard_stepper:
step_pin: I2SO.4
direction_pin: I2SO.5
disable_pin: I2SO.3
# use E1 driver for 2nd Y axis motor
motor1:
limit_neg_pin: NO_PIN
hard_limits: false
pulloff_mm: 4.000
standard_stepper:
step_pin: I2SO.13
direction_pin: I2SO.14
disable_pin: I2SO.12
z:
steps_per_mm: 200.000
max_rate_mm_per_min: 8000.000
acceleration_mm_per_sec2: 60.000
max_travel_mm: 80.000
soft_limits: false
homing:
cycle: 1
positive_direction: true
mpos_mm: 0.000
feed_mm_per_min: 300.000
seek_mm_per_min: 500.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_pos_pin: gpio.22:low:pu
hard_limits: true
pulloff_mm: 3.000
standard_stepper:
step_pin: I2SO.7
direction_pin: I2SO.8
disable_pin: I2SO.6
control:
safety_door_pin: NO_PIN
# on MT_DET connector
# reset_pin: gpio.35:low
reset_pin: NO_PIN
# on TH1 connector
feed_hold_pin: gpio.36:low
# on TB connector
cycle_start_pin: gpio.39:low
macro0_pin: NO_PIN
macro1_pin: NO_PIN
macro2_pin: NO_PIN
macro3_pin: NO_PIN
# coolant:
# # Heated Bed Terminal Block
# flood_pin: i2so.16
# # HE0 Terminal Block
# mist_pin: i2so.17
# delay_ms: 0
# spindle PWM signal
PWM:
pwm_hz: 2500
# on EXP1 IO15 connector.
# note IO15 will give some short pulses on boot, which may activate spindle
# use IO17 on EXP1 to avoid
output_pin: gpio.15:high
s0_with_disable: true
tool_num: 100
spinup_ms: 4000
spindown_ms: 4000
speed_map: 8000=0.000% 18000=100.000%
Laser:
pwm_hz: 5000
# on 3D Touch connector (has pdwn + PWM)
output_pin: gpio.2:high:pd
s0_with_disable: true
tool_num: 1
speed_map: 0=0.000% 1000=100.000%
probe:
pin: gpio.35:pu:low
check_mode_start: true
start:
must_home: false
uart2:
txd_pin: gpio.4
rxd_pin: gpio.13
rts_pin: NO_PIN
baud: 9600
mode: 8N1
Huanyang:
uart_num: 2
modbus_id: 1
tool_num: 0
speed_map: 0=0% 0=25% 7200=40% 18000=100%
off_on_alarm: false
Just digging into the code here. It looks like for me it's failing just after the state command message check (GetParserStateCommand.java
). This is what I get on my controller:
$GCode/Modes
[GC:G38.2 G54 G17 G21 G90 G94 M5 M9 T0 F100 S0]
ok
Assuming UGS gets this message, GrblUtils.isGrblFeedbackMessageV1
should pass, as it starts with [GC:
. There's no ConnectionException
or I'd get a failure message.
String state = getParserStateCommand.getState().orElseThrow(() -> new ConnectionException("Could not get controller state"));
gcodeParser.addCommand(state);
Hold on, let's look at the logs. There's the issue. It's failing when it adds the state.
SEVERE [FluidNCController]: Could not initialize the connection
com.willwinder.universalgcodesender.gcode.util.GcodeParserException: Axis words missing for motion command: G38.2
at com.willwinder.universalgcodesender.gcode.util.GcodeParserUtils.handleGCode(GcodeParserUtils.java:266)
at com.willwinder.universalgcodesender.gcode.util.GcodeParserUtils.processCommand(GcodeParserUtils.java:154)
at com.willwinder.universalgcodesender.gcode.GcodeParser.addCommand(GcodeParser.java:147)
at com.willwinder.universalgcodesender.gcode.GcodeParser.addCommand(GcodeParser.java:134)
at com.willwinder.universalgcodesender.firmware.fluidnc.FluidNCController.queryControllerInformation(FluidNCController.java:612)
Here's the full log file. messages.log
Thanks for the log.
UGS parses all commands sent to the controller and mirrors its state. To get the initial state the command $GCode/Modes
is sent and appended to the state.
But according to the Gcode spec, at least one axis must be applied together with the G38.2 command. UGS has implemented this as a rule and throws this error.
The solution is to relax the gcode parser to allow G38.2 commands without a defined axis.
Version
2.1.2
Hardware / Firmware
FluidNC
What happened
on attempting to connect to fluidnc with any version of ugs above 2.0.13 I receive the following: Connecting to tcp://192.168.0.210:23 Fetching device status Fetching device firmware version Expected a 'FluidNC 3.3.0' or later but got 'Unknown 0.0.0' Could not establish connection with the controller Connection closed
but it works fine with 2.0.13 and I get this: Connecting to tcp://192.168.0.210:23 Fetching device status Fetching device firmware version Fetching device status codes Fetching device state Fetching device settings *** Connected to FluidNC 3.7.11
and everything works just fine. I have attempted this with several versions of fluidnc to make sure that it was not the firmware causing the problem and it seems to be UGS platform as all of the versions above 2.0.13 give the same error and disconnect status.
How to reproduce
I am connecting through wifi and have not tried to connect locally but I will give that a try when I have a chance and update how that went.
Operating System
win64
Anything else
This happens every time. It will not work with versions above 2.0.13 but works perfectly and every time with 2.0.13