I like using the webUI to control my MPCNC but finding that connecting via AP wifi causes lots of little headaches.
disconnects and reconnects to home wifi if iPhone goes to sleep
repeatedly having to reboot the jackpot due to “password incorrect” error
gcode failing to fully upload leaving a partial file on the SD card.
All the above issues are with my phone (or iPad) inches away from the radio.
So my question is, can I connect via USB to a computer(PC, Mac or Chromebook) and still use the webUI to control things? After my the board decided to not let me reconnect at tool change and I had to resort to powering off and start over, I figured I would ask.
If your current workflow doesn’t work well with AP mode, you have a few options.
Buy a cheap dedicated tablet to use as a controller. Many can be found for under $50 that would suffice.
Use STA mode to connect the machine to your home WiFi so you don’t have to switch networks. This is only recommended if you have a strong connection out near the machine.
For a USB connection, you can use a sender like UGS. One of the FluidNC devs is also a UGS dev so it should have good support, however, I don’t use this so I don’t what kind of difficulties you might encounter. I, personaly, prefer to run everything direct from the SD card instead of using a sender to stream GCode. If UGS can do this (I don’t know), then your jobs can still run the same
FluidNC team recently released the FluidDial which is a pendant that can give local control of a lot of things without a web connection, but it is not a 100% replacement for the WebUI. This is also a fairly new project and may not be 100% stable yet. The cost though is probably going to be roughly the same as just getting a dedicated tablet as an interface, so you’d need to weigh options there.
That being said, I don’t have any of the issues you mention above.
I am careful to disable screen auto-shutoff if I have a job running and keep my tablet charged.
The file upload thing I think is not necessarily related to your network, it just fails sometimes on large file uploads. Direct SD card transfer is much more reliable, and my primary transfer method.
Once you are running a job, you cannot hit refresh on the webpage if you have the setting $HTTP/BlockDuringMotion enabled (this is enabled by default). This is likely why you got locked out on tool change.
I’ve never seen this “password incorrect” issue personally, but I have seen it mentioned before, so I can’t help with that one
I have shied away from STA mode after reading that it’s not recommended. but I do want to try it.
I mostly use the webUI for homing/squaring and jogging around, and starting a job. Ill look into UGS.
$HTTP/BlockDuringMotion enabled
I have seen pop up before but the issue I was having last night was no device I tried could connect to the wifi. it kept saying “password incorrect”.
With all that being said, you answered my question that you cannot access the webui via a USB connection. Only accessible via wifi connection.
Only do this if you have a strong signal to your home wifi network at your CNC machine. If you have a strong connection, it is fine.
I will add, if you want to look at teh webui while the machine is running it is best to tell your device not to go to sleep, or turn off $HTTP/BlockDuringMotion enabled…if you do that be careful not to constantly refresh your screen.
Also I will add, you might want to update to 3.7.12 if you are on anything older, each update the network seems to be getting a bit better.
If you had connected before, you may have to go and “Forget this network” on the device and try to reconnect completely. I don’t know what could cause it to happen, but it sounds like it doesn’t like something in the way the network settings were saved
You can also use cncjs or octoprint with the usb connection. The only warning is to make sure the jackpot is powered before you connect the USB. If you power the USB before the jackpot, the TMC drivers will get a signal before they are powered and wont configure properly.
I recently realized you can send $MI at the FluidNC terminal at any time to have FluidNC attempt to initialize the stepper drivers. Better to just power the board up before conecting your USB, but in some situations it’s possible to recover from starting with only having USB.
It also lets you re-apply the driver current setting if you edit the config.yaml, without needing to power cycle the board for this to take effect.
I wonder if the jackpot can detect that situation and $MI itself. Either by sensing power to the drivers. Or just by not getting the data back on the uart. Maybe this is a good opportunity for a pull request.
Another option might be to do a complete reboot when 12V power is applied. But that might have negative side effects.
When I first sign into a jackpot, I get one of three responses in the terminal. That in itself seems weird to me, why do they not all have the same initial response.
Then when I run $ss I either get a “complete” response, one with the firmware, setup info, driver settings, driver status, and then some network info. On others any combination of those sections can be missing or partial. I have noticed that on some just rebooting is fine. (They always seem to be perfect over USB terminal)
I need to find a board that has some missing $ss info and try the $mi and see what happens.
If it does work, I think either a PR is needed, or maybe just a boot macro, something like delay 3 seconds then $MI.
That’s a good step. But it would miss the case of someone plugging in USB >3s before powering on the 12V. It would be better if the esp just recognized it wasn’t set up and periodically tried MI to fix it. It is a computer, it probably won’t hurt it to call it often. It just need to call it often enough that it will happen between turning on 12V and doing any jogging. Every second or 10 seconds is probably fine.
I was pondering this earlier today.
$MI would be a useful thing to have as a button on the WebUI on a utility panel somewhere, with the other commonly used/requested troubleshooting steps like $SS.
Before I report it I would love if one of you could confirm it. I just tried it on two differnt boards.
Everything works as expected, full $ss, genuine esp’s. Run $MD, works as expected. Run $MI report is good, Z does not actually enable though. I can move it and it will stay enabled, but just not after $MI.
When the board boots Z is enabled as expected, just not after $MI
So on the LR config $MI works…but $MD doesn’t (once and a while it does). It reads as if it happens “disabling all steppers” but they are clearly all still engaged.
I’ll create a topic about this at some point soon, but for the moment am going to work on troubleshooting the $MI / $MD thing. I created a new topic here:
I’m glad my question has sparked a broader conversation :).
I do want to share that moving to sta mode made a world of difference. It’s running so much smoother.
I did notice that when I went into settings it was on sta > ap but had no ssid or password. So I added those. Maybe just switching directly to Access Point would have solved some issues.
