Move controls greyed out with FluidNC

I am a FluidNC developer. I am testing MillMage with FluidNC because I expect that our users will have questions. I set up a SerialUSB device using the GRBL GCode flavor, with Enable DTR on, Enable $J Jogging on, Query regularly for tool position on. Text Based on, Buffered Transfer mode, Target Buffer size 127.

MillMage connects and displays startup messages in the Console window. After receiving the “Grbl 1.1f [$ for help]” signon message, MillMage appears to issue $I and $G commands to which FluidNC responds with

[VER:3.9 FluidNC v3.9.7:]
[OPT:MPHS]
[MSG:Machine: TMC2209 IO Test]
MSG:Mode=STA:SSID=CampOlindaHS:Status=Connected:IP=192.168.4.56:MAC=2C-BC-BB-28-2C-58]
ok
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
ok

This all seems reasonable, but when I select the Move tab, everything is greyed out - positions, controls, everything.

In the Console, I can type commands and get the expected results. $H homes the machine and the console shows that a ? was issued with the expected <Idle|MPos…> status report. G0 commands move as expected. $J=… jog commands work as usual.

Is MillMage expecting a particular form of response to some inquiry before enabling the Move controls?

That’s really strange Mitch. I have the same settings and the Move tab works with my Jackpot. Is there anything you would like me to check for you?

Just restart MillMage.

The very first time you open it with no existing preferences, some weird stuff can happen in the UI (chicken before egg). I’ll put in a bug report.

2 Likes

Bug report is done.

A big welcome by the way Mitch!

A few weeks ago I watched a video where you talking to a group about FluidNC (FluidNC DIY CNC – Mitch Bradley – 2023-11-18), it’s was from more than a year ago but super interesting.

For the record, I nearly fell off the edge of my seat at 20:30 when you were interrupted! What? - no please keep talking! LOL

I really like FluidNC (use it with the V1 Engineering LowRider3), and appreciate the work you and Bart Dring have put in to it - and Bart’s Jackpot controller is great.

3 Likes

Just want to second Nicks words. We plan to make a FluidNC flavor soon so if there’s any special handling that can get better for FluidNC please let me know. I’m happy to do a call with you guys to talk more about good support for Fluid as well.

2 Likes

Restarting fixed it; thanks.

1 Like

One feature that might be worth supporting is auto-reporting. If you send $report/interval=200, for example, FluidNC will automatically issue a <…> status report when (a) the state (Idle, Hold, …) changes or, when in a motion state, every 200 milliseconds. That makes the UI quite responsive without having to send rapid-fire ? commands.

It also auto-reports the GCode modal values [GC: …] so the UI can see, for example, changes in the WC system due to the execution of, say, G55, in a GCode program running from an SD file.

That’s interesting. We were just discussing how to handle G54 changing if someone ran the zeroing macro from a fluid pendent after they had set a TLO and that might help.

Thanks for that info!

Another possibility for FluidNC optimization: For the device setup, you could preset the Working Size and Zero Point Configuration from the results of $/axes/{x,y}/max_travel_mm, $/axes/{x,y}/homing/positive_direction, and $/axes/{x,y}/mpos_mm

I’m not sure how that would fit with the existing setup flow, since you would have to do the communication setup and connect before inquiring about those parameters. I suppose there could be an “auto” option in the setup dialog that would defer the settings until later.