FluidNC support

[petervanderwalt]

Released as of 1.0.342

• Basic comms
• platform ID
• Config dump

Left on Todo:

• Config edit
• Config presets for machines
• xModem upload of config files
• Config parse for CONTROL's "grblParams.xx" needed values (below)
• Workaround for disabling queryloop during config dump
• Add FluidNC to Flashing Tool

[petervanderwalt]

Todo Yaml parse https://www.npmjs.com/package/yamljs into legacy $$ setting as used by other parts of CONTROL

grblParams.$30 : used by Tool On > Variable
grblParams.$110 : used by JogRate X
grblParams.$111 : used by JogRate Y
grblParams.$112 : used by JogRate Z
grblParams.$113 : used by JogRate A
grblParams.$22 : Used by jog
grblParams.$27 : Used by Goto Zero Machine Coordinates (pull off from switch)
grblParams.$20 : Used by Softlimits calculation
grblParams.$130 : Used by Softlimits calculation, Machine extents on 3D view
grblParams.$131 : Used by Softlimits calculation, Machine extents on 3D view
grblParams.$132 : Used by Softlimits calculation, Machine extents on 3D view
grblParams.$133 : Used by Softlimits calculation, Machine extents on 3D view
grblParams.$100 : Calibration: X
grblParams.$101 : Calibration: Y
grblParams.$102 : Calibration: Z

[petervanderwalt]

Basic fluidnc config file bdring/FluidNC@4af173b made by @synman

[synman]

I've created a wiki here: https://github.com/synman/Octoprint-Bettergrblsupport/wiki/Hacking-the-OpenBuilds-BlackBox-X32

[petervanderwalt]

bdring/FluidNC#755 relates - but needs a couple adaptations to be more compatible with the typical OpenBuilds Machine kit

[petervanderwalt]

https://openbuilds.com/threads/just-discovered-openbuilds-control-with-fluidnc.20338/#post-134242

Disable "?" statusloop while dumping config file, fluidNC responds to realtime commands in the middle of the config dump

[curieos]

I tried using the latest OBC with a machine running FluidNC today, and it went mostly well. I had two major things I was having issues with, one was connecting over USB. Not sure why, it sounded like that was working for this person based on the forum post:

https://openbuilds.com/threads/just-discovered-openbuilds-control-with-fluidnc.20338/#post-134242

Connecting over the network worked surprisingly well. I'd have occasional delays while jogging using the web interface, but during the several hours using OBC, even on the mobile jog widget, I did not have any noticeable delay when jogging. No stuttering during running a program either. The OBC probing wizard also worked without issue, though I suppose that's to be expected, since FluidNC uses the same codes for that as GRBL.

The second issue I had was the "Home All" button in OBC was disabled, so I had to send $H in the console to get the machine to home. Any reason for this?

[petervanderwalt]

issue I had was the "Home All" button in OBC was disabled, so I had to send $H in the console to get the machine to home. Any reason for this?

Thats the above todo item ^

• Config parse for CONTROL's "grblParams.xx" needed values (below)

We disable the button when homing is disabled in Grbl's settings. FluidNC's different config means we need to write code to parse its config and see if homing is enabled or not to update the button accordingly

[curieos]

Do you have an ETA on when you think you'll be able to work on this? I downloaded the source and figured out how to build the app in preparation to take a stab at it, but I don't know how useful my contributions will actually be, especially if you plan to work on this more in the next couple weeks.

If it will be a while and you would like the help, could you give me some guidelines for how you want things implemented please?

[petervanderwalt]

Do you have an ETA on when you think you'll be able to work on this? I downloaded the source and figured out how to build the app in preparation to take a stab at it, but I don't know how useful my contributions will actually be, especially if you plan to work on this more in the next couple weeks.

If it will be a while and you would like the help, could you give me some guidelines for how you want things implemented please?

No ETA at the moment, as we are a small team we circle between projects based on current business priority, and we are working on three or four new exciting hardware projects at the moment. grbLHAL still serves us well, so unfortunately not able to commit time to this at the moment over the other priorities.

Your approach of offering help is a good one though - its not unwillingness on our side, but rather a lack of time.

Happy to talk you through what needs to be done (summarised above)

The main bulk of the todo is in that fluidNC drastically changed configs from grbl's $1=xx style (grblHAL stuck with it, so adding grblHAL support was way easier)

To support fluidNC properly, before we can declare support for it, means being able to read, edit, save configs.
It means having all our machine profiles converted to fluidNC configs so people can load them as easily as they can do now (CONTROL > Grbl Settings tab > Select machine from list > Save > Reset when prompted)
And then we do have some functionality in CONTROL that looks at grbl Settings values (Above noted all of the ones I know about) - we can just populate a fake grblParams object from reading the YAML for that, rather than rewriting all those sections.

As for editing, we'd love it to be as simple as we made editing Grbl configs - table layout etc. Maybe parsed yaml, draw up the table but have a tab/button for advanced editing allowing direct yaml editing

Uploading the configs over xmodem is also a task that haven't been completed yet (xmodem.js has been added as dependency already

OpenBuilds-CONTROL/package.json

Line 32 in f724560

"xmodem.js": "^0.1.0"

but not built into index.js yet)

We also need to bring it into the Flashing tool (: but that's relatively simple

As for our machine profiles, if we work clever on the Editing UI, we can probably use the existing grbl templates to update a generic Yaml and let it rip (rather than keeping two sets of configs updated) - we did that for the grblHAL profiles too, use the grbl 1.1 profile, then just fix up some values that needed changing

OpenBuilds-CONTROL/app/js/grbl-settings-defaults.js

Lines 4 to 24 in f724560

	function fixGrblHALSettings(j) {
	if (laststatus.machine.firmware.platform == "grblHAL") { // Workaround for HAL profiles required changes, without creating entirely new profiles for GrblHAL
	if (j == "10") {
	// Status Report Format
	$("#val-" + j + "-input").val(511)
	}
	if (j == "5") {
	// Fix NC vs NO switches
	$("#val-" + j + "-input").val(7)
	}
	if (j == "6") {
	// Fix Probe Inversion
	$("#val-" + j + "-input").val(1)
	}
	if (j == "4") {
	// Fix Enable Invert
	$("#val-" + j + "-input").val(0)
	}
	}
	}

Oh and another fluidNC oddity we need to work around #283 (comment)

[curieos]

Sorry for not responding, I had a very busy week. Thanks for the info. I created a workaround for the oddity.

I also figured out why I was having difficulties connecting over USB. When booting, if wifi is enabled, the boot process takes longer since it connects to the network before spitting out the status message with grbl at the front. The first message it sends is [MSG:INFO: FluidNC vX.X.X]. Initially, I extended the connection timeout to get it to work temporarily, but it requires an excessively long timeout (around 15 seconds). I came up with a somewhat hacky solution that prevents the grbl socket from being emitted until the standard grbl message gets received when OBC detects the FluidNC intro message.

I also got config parsing functional. I don't think it's the cleanest, so I'm going to take another pass at it before I make that live.

[curieos]

I pushed my changes. I rewrote the parsing code to use lodash since it handles failing to find properties nicely. There's definitely more work to do, but I think I've gotten it to a minimum viable level for my purposes. I'll put some more work into managing the config in OBC when I get some time.

[rhinodavid]

Update: See below. the GRBL version is actually 1.1, the FluidNC version is 3.7.

Team --
I've tried about a half-dozen Gcode senders with FluidNC and CONTROL, as is, is hands-down the best.

The FluidNC GRBL Gcode senders page unfortunately doesn't list CONTROL, but I'm going to try and get Wiki access and add it.

One issue I did notice:
The default FluidNC startup message reads like Grbl 3.7 [FluidNC 3.7.10 (wifi) '$' for help], and CONTROL does not correctly parse it (I think it ends up using "Method 2", which I can't find in the code after a short look).

The log looks like:

[23:18:09] [ connect ] Detecting Firmware: Method 2 (Ctrl+X)

[23:18:09] [ ] Detected an unsupported version: Grbl .7.10. This is sadly outdated. Please upgrade to Grbl 1.1 or newer to use this software. Go to http://github.com/gnea/grbl

[23:18:09] [ ] Grbl 3.7 [FluidNC 3.7.10 (wifi) '$' for help]

[23:18:12] [ connect ] Firmware Detected: grbl version .7.10 on 192.168.0.55

Luckily, one can change the startup message.

Changing the startup string to Grbl \V [\H] will output Grbl 3.7 ['$' for help] and eventually you'll have a log line:

[23:23:04] [ connect ] Firmware Detected: grbl version 3.7 on 192.168.0.55

The startup message can be changed with the $Start/Message command or via the GUI.

Hope this helps someone. -d

[dJOS1475]

I found the easiest way to get Control working properly with FluidNC was to set the firmware to “ Grbl 1.1g”. Then it works great:

[synman]

@dJOS1475 I may still have wiki access and can ask Bart about it if you'd like.

They are fairly active on Discord.

[synman]

Something to keep in mind though with your work around... It may impact other senders that have been fully updated to support FluidNC.

I guess that isn't such a big deal if you plan on sticking with Control, but it is worth mentioning for others.

I also thought we had/have a fork here where this was worked out

[rhinodavid]

Any chance somebody can give me a code pointer to the GRBL detection logic. I've been string searching and can't seem to find it.

[viernullvier]

I've just updated my controller to the latest FluidNC build (3.7.13) and dug around in the OpenBuilds Control code - looks like we're almost there.

First, FluidNC has added support for a major chunk of legacy GRBL settings. Sending $$ will return a config that is understood by OBC and will update the UI accordingly.

Second, I looked into a way to have OBC send the $$ command directly after connecting. As it happens, this is the same behaviour as expected for GrblHAL, so I just set up my controller to impersonate GrblHAL:

Setting Start/Message to GrblHAL \B (\R) \H allows me to use the controller without issues, but of course it forgoes any FluidNC-specific functionality in OBC that might already be there. If someone reading this discussion just wants to get OBC v1.0.370 to work with FluidNC v3.7.13, this is the thing to change.

Here's my take on the remaining open tasks :

• Config parse for CONTROL's "grblParams.xx" needed values:
  This might no longer be needed since OBC can now just use $$ in the same way as other firmwares.
• Workaround for disabling queryloop during config dump:
  If OBC switches to $$ config reporting for FluidNC, this workaround is no longer needed.
• Config edit:
  @petervanderwalt How intricate do you envision this to be? Should it be an editor like the current one for the classic GRBL config or would it be enough to let the ACE editor write the config back to the controller? If it's the latter, there are a couple things to keep in mind:
  • The output of $CD is not an accurate representation of the config file according to the local file system. Some missing parameters are added with their default values, while comments are stripped out.
  • The actual config file can be retrieved via $LocalFs/Show=config.yaml.
  • It is possible to have multiple different config files on the same controller and switch between them. To check if a different config file is used, the active config file name can be fetched via $Config/Filename first.
• Config presets for machines:
  Turning the existing presets into a FluidNC YAML could just be as simple as a JS template literal. Of course, this will only be half the battle because FluidNC will also require a hardware configuration. OBC could however provide a base config at least for the X32 which can then be amended with the preset YAML.
• xModem upload of config files and Add FluidNC to Flashing Tool:
  Those two should just be a matter of doing the work.
• There's also one extra task that's already been discussed here, but not mentioned in the initial to-do:
  The firmware version detection logic needs to be fixed.
  OBC expects a string like Grbl 3.6 [FluidNC v3.6.5 (wifi) '$' for help], but the v prefix has never been part of the default FluidNC version string. This leads to the issue that @rhinodavid described - the version string is offset by one character and therefore interpreted as an unsupported pre-1.1 GRBL build (relevant code). A proper, more stable solution would just use a regex to extract the major and minor version.

I'd be willing to take care of the following:

• Remove previous attempt of FluidNC YAML parsing, use config returned by $$ instead
• Fix version detection, add warning when attempting to use a pre-3.7.13 version of FluidNC
• Add support for config backup/restore/save to firmware (hardcoded to config.yaml at first)
• Try to add support to the flashing tool if it is really as simple as @petervanderwalt described it

How does that sound?

[dJOS1475]

Funny you mentioned GrblHAL, I’ve just ditched FluidNC for it. I was just not 100% happy with it. GrblHAL Has been rock solid.

https://youtu.be/u_wgNvjDEF4

[NeOdYmS]

how can i contribute on this issue ?

[petervanderwalt]

First, FluidNC has added support for a major chunk of legacy GRBL settings. Sending $$ will return a config that is understood by OBC and will update the UI accordingly.

That's very good news, the different settings thing needed a lot of work to accomodate, so that should ease adoption, I think? Reusing the Grbl Settings we have now (even with some modification, still friendlier than editing Yaml)

I'd be willing to take care of the following:

• Remove previous attempt of FluidNC YAML parsing, use config returned by $$ instead
• Fix version detection, add warning when attempting to use a pre-3.7.13 version of FluidNC
• Add support for config backup/restore/save to firmware (hardcoded to config.yaml at first)
• Try to add support to the flashing tool if it is really as simple as @petervanderwalt described it

How does that sound?

That sounds great! I am allocated on CONTROL for a couple days this week, so please help! Happy to Merge pulls, just don't have a lot of time to work on it myself (:

[petervanderwalt]

Any chance somebody can give me a code pointer to the GRBL detection logic. I've been string searching and can't seem to find it.

OpenBuilds-CONTROL/index.js

Lines 1459 to 1528 in 8de3ace

	// Machine Identification
	if (data.indexOf("Grbl") === 0) { // Check if it's Grbl
	debug_log(data)
	status.comms.blocked = false;
	if (data.indexOf("GrblHAL") === 0) {
	status.machine.firmware.type = "grbl";
	status.machine.firmware.platform = "grblHAL"
	status.machine.firmware.version = data.substr(8, 4); // get version
	} else if (data.indexOf("FluidNC") != -1) { // Grbl 3.6 [FluidNC v3.6.5 (wifi) '$' for help]
	status.machine.firmware.type = "grbl";
	status.machine.firmware.platform = "FluidNC"
	status.machine.firmware.version = data.substr(19, 5); // get version
	} else {
	status.machine.firmware.type = "grbl";
	status.machine.firmware.platform = "gnea"
	status.machine.firmware.version = data.substr(5, 4); // get version
	}
	if (parseFloat(status.machine.firmware.version) < 1.1) { // If version is too old
	if (status.machine.firmware.version.length < 3) {
	debug_log('invalid version string, stay connected')
	} else {
	if (status.comms.connectionStatus > 0) {
	debug_log('WARN: Closing Port ' + port.path + " / v" + parseFloat(status.machine.firmware.version));
	// stopPort();
	} else {
	debug_log('ERROR: Machine connection not open!');
	}
	var output = {
	'command': command,
	'response': "Detected an unsupported version: Grbl " + status.machine.firmware.version + ". This is sadly outdated. Please upgrade to Grbl 1.1 or newer to use this software. Go to http://github.com/gnea/grbl",
	'type': 'error'
	}
	io.sockets.emit('data', output);
	}
	}
	status.machine.firmware.date = "";
	// debug_log("GRBL detected");
	// setTimeout(function() {
	// io.sockets.emit('grbl', status.machine.firmware)
	// //v1.0.318 - commented out as a test - too many normal alarms clear prematurely
	// //io.sockets.emit('errorsCleared', true);
	// }, 600)
	// // Start interval for status queries
	// clearInterval(statusLoop);
	// statusLoop = setInterval(function() {
	// if (status.comms.connectionStatus > 0) {
	// addQRealtime("?");
	// }
	// }, 200);
	status.machine.modals.homedRecently = false;
	} else if (data.indexOf("LPC176") >= 0) { // LPC1768 or LPC1769 should be Smoothieware
	status.comms.blocked = false;
	debug_log("Smoothieware detected");
	status.machine.firmware.type = "smoothie";
	status.machine.firmware.version = data.substr(data.search(/version:/i) + 9).split(/,/);
	status.machine.firmware.date = new Date(data.substr(data.search(/Build date:/i) + 12).split(/,/)).toDateString();
	// Start interval for status queries
	// statusLoop = setInterval(function() {
	// if (status.comms.connectionStatus > 0) {
	// addQRealtime("?");
	// }
	// }, 200);
	var output = {
	'command': "FIRMWARE ERROR",
	'response': "Detected an unsupported version: Smoothieware " + status.machine.firmware.version + ". This software no longer support Smoothieware. \nLuckilly there is an alternative firmware you can install on your controller to make it work with this software. Check out Grbl-LPC at https://github.com/cprezzi/grbl-LPC - Grbl-LPC is a Grbl port for controllers using the NXP LPC176x chips, for example Smoothieboards",
	'type': 'error'
	}
	io.sockets.emit('data', output);
	stopPort();
	} // end of machine identification