can not connect to fluidnc because of incorrect version information

[wtfiAndrewNelson]

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

[breiler]

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.

[wtfiAndrewNelson]

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?

[breiler]

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.

[breiler]

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

[wtfiAndrewNelson]

Just gave it a try and it works brilliantly!

[shampeon]

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

[breiler]

I can't reproduce this with the UGS nightly build 20240102 and fluidnc 3.7.12. Can you post your FluidNC configuration.

[shampeon]

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

[shampeon]

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)

[shampeon]

Here's the full log file.
messages.log

[breiler]

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.