Proposal to enhance Setup wizard for FluidNC

[shampeon]

Description

Current behavior

Currently, UGS assumes that the connection driver has already been set correctly when selecting the firmware and connection settings. When UGS essentially only supported serial connections because most controllers were connected using a local serial connection, that was a reasonable assumption.

What problem does this feature solve?

Newer controllers can be controlled over the network, either directly with TCP or using Websockets. FluidNC is an example of a newer CNC controller that is overwhelmingly accessed over the network.

The FluidNC maintainers explicitly tell users to use more full-featured senders like UGS so they can concentrate on just connecting to and controlling the CNC machine itself.

When a new user is presented with the connection options in the Setup wizard as it exists today, and they want to connect to a networked controller, it's not clear that they need to change the connection driver from the default JserialComm driver to TCP.

Once the user figures out they need to change the driver, it's a relatively high number of UI actions to close out the Setup wizard, open the Connection panel, change the driver, restart the Setup wizard, and then attempt the connection.

This can be simplified and provide a better initial user experience (and with fewer obnoxious support requests) by adding additional behavior to the Setup wizard.

Proposed behavior

The Connection setup wizard should allow the user to select the connection driver from within the wizard. Users can then choose how they will connect to the controller within a single UI panel. Users can switch back and forth from within the wizard for controllers that can connect through both serial or network connections.

Initial proposal (abandoned)

A Setup wizard can be more opinionated about connection options and default values.

The Setup wizard should make reasonable assumptions about the controller to which is connects. If e.g. the user selects FluidNC or Smoothieware, it is reasonable to assume that the type of connection is over the network, so the connection type should be set to a TCP from within the wizard itself. The UI can inform the user that selecting FluidNC or Smoothieware will change the default driver, and allow the user to cancel out if that's not desired.

After the user selects e.g. FluidNC, and the input boxes are updated to reflect the options required for TCP connections, the options should be prepopulated with any appropriate values for that firmware. In the case of FluidNC, the default port for TCP connections is the Telnet port, 23.

Alternatives considered

The Setup wizard could alert the user that the preferred driver for a given firmware choice is not currently active. This would point users towards the correct action of changing the driver, as right now there's no feedback from UGS that they are on the wrong path. This would be simpler to implement. The downside is that the user would have to take additional action by manually closing out the Setup wizard, opening the Options dialog, navigating to the Sender Options pane, selecting the correct driver, applying the changes, closing the Options dialog, then restarting the Setup wizard.

Edit: This alternative was chosen as correct solution. The Setup wizard could add a driver combo box so users could select the driver from within the wizard before choosing the firmware. This again is a simpler option to implement than the proposal. The downside is that users might not understand which driver is the preferred driver for a given firmware choice, and just move on to selecting the firmware while leaving the current driver unchanged. This will result in connection errors, and probable user frustration.

Goals and non-goals of this feature

Goals:

• Add the ability to dynamically change the connection driver based on the firmware type to the Setup wizard.
• Provide reasonable defaults to the user in the Setup wizard based on the selected firmware.
• Provide a generalized framework for giving configuration hints to firmware types.

Non-goals:

• Refactor the Setup wizard.
• Validate user provided configuration options.
• Troubleshoot connection problems within the Setup wizard.

[shampeon]

Question: where do we store the configuration defaults?

It probably makes most sense to add them to the firmware_config JSON files.

Something like:

{
    "Name": "FluidNC",
    "Version": 3,
    "Controller": {
        "name": "FluidNC",
        "args": null
    },
    "ConfigDefaults": {
        "driver": "TCP",
        "host": "",
        "port": "23"
    },

[shampeon]

If the config is stored in the JSON files, we'd have to update any existing files in the old format. It looks like this is handled already by FirmwareUtils.

[breiler]

By making FluidNC default to TCP you are making the assumption that most users will be using WiFi. Based on the few questions we have got about how to switch to the TCP-driver I don't think this is true. It could of course also mean that the users don't even know that you can connect over TCP.

I think the best approach is to start with adding the ability to dynamically change the connection driver and see if that becomes intuitive enough.

[kevindt]

As a FluidNC user using a wired connection, I'd agree with Breiler. Making it easier to configure initial settings to use TCP if desired is good but making it the default option for FluidNC may not be. I'd like to see the evidence for the statement "FluidNC is an example of a newer CNC controller that is overwhelmingly accessed over the network". Most FNC users that I know use wired connections, but we may be a minority of the overall population.

[shampeon]

Ok, I will add a selector for the driver. The (unscientific) poll Breiler added to the FluidNC Discord server indicated 70% of Gcode sender users connect using serial and 30% over the network. So, a significant, and likely growing, number of users, but not enough to make it the default.

[kevindt]

Thanks for the (unscientific) information :). Seeing your reply, I went and looked for that poll on the Discord - and it certainly is not anything to base much reliance upon!
I'm pretty new to UGS, which I'm definitely coming to like. My current main machine is a Carbide 3D 5 Pro, though I've been building machines since Mach 3 and XP parallel ports. The bundled controller and software are good for their purpose but are limiting for things like PCB work where height-mapping is a big plus. There are also some controller design issues as well as using non-open-source firmware.
So, I decided to build my own controller around open-source software and mainboards.
I've tried a GrblHAL Teensy-based board and IoSender/Candle - which was OK.
I've settled currently on Bart Dring's FNC with a 6-Pack external driver board. Bart and Mitch's level of commitment to their project is what swings the needle in their direction. It's early days yet, but so far UGS has been working well with it. My own connections to FNC via wireless have been restricted to wireless firmware updating, uploading FNC YAML config files and occasional testing. Even those are mostly done over USB here. All actual machine usage has been via UART serial connections (USB or otherwise).
That doesn't mean that I'd not be happy to try wireless - I have a separate testbed currently in use for pendant testing and I'd certainly be willing to join in with any testing efforts to help out if needed. I'm not a Java programmer, but I'm used to working in C/C++ as a hobbyist (only) - including playing with FNC and the current work on a (wired) pendant.

[shampeon]

Working on a PR.

[shampeon]

FWIW, to get a working version to test on macOS (Monterey), I had to:

1. Install crdtools:

   brew install cdrtools

2. Build but skip the tests:

   mvn install -DskipTests=true

3. Create a package:

   mvn package -pl ugs-platform/application -P create-macosx-x64-package -DskipTests=true -Drevision="2.0" -DchangeList=""