I had to turn off Lan Wi-Fi and use the generated host from the M4 FluidNC password 12345678.
go to FluidNC and reset the names in the flash settings.
Check STA/SSID and Password matches your Wi-Fi
Power reset the M4 and you should be able to login again
Sorry it took so long to get back to you I am in Australia.
1 Like
Option B - Incidentally I didn’t replace the maslow.yaml fille when I updated to 78, and renaming the entries in Flash settings has got me back working. haven’t had a chance to test anything except the Zaxis yet.
1 Like
Personally I would not have put any untested code into the git “release” section without big “BETA” or “TEST ONLY” tag or labels in the description.
Is there a way to flash firmware.bin, index.html.gz and maslow.yaml onto the esp32 over USB on Linux?
Mine connects to the local network but the web UI is stuck forever loading with a white webpage.
Well that was a bit of a PIA.
git clone https://github.com/BarbourSmith/FluidNC
cd FluidNC/install_scripts/posix
unzip ~/Downloads/fluidnc-maslow4-0.78.1.-win64.zip
cp -a fluidnc-maslow4-0.78.1\ -win64/wifi_s3 wifi
cp -a fluidnc-maslow4-0.78.1\ -win64/common .
cp -a ../../fluidterm .
mv fluidterm common/
cp common/fluidterm/fluidterm.py common/
chmod +x *.sh
./install-fs.sh
which flashed the index.html.gz into the esp filesystem and now, since it has v0.77 firmware it blinked the ip address and I got the web UI working.
I uploaded v0.77 of the maslow.yaml and things are looking better.
2 Likes
I’ve run into a similar problem. Although loading .75-.77 has not seemed to bring it back to life. I’m currently getting this failure…
If you are on windows, you can attach a USB-c to the maslow from your computer and use whats in the fluidnc-maslow4-0.77.win64.zip (or whichever firmware) file to “factory reset” the maslow to that version.
2 Likes
if you’re on Linux I can help you with that since I just hacked the install-scripts section to use files from the windows-only release package(fluidnc-maslow4-0.77.win64.zip ) so I could run the install-fs.sh script and get the firmware loading the web server.
1 Like
I think you should put a big disclaimer on 0.78 that says DO NOT USE. There is just no upside in having anyone install it.
3 Likes
Agreed, should have description noting not to use it and v0.78.1 supersedes it. Should never have been posted without a single test install of it.
I’ve had on my Linux PC system firmwares v0.77(running), v0.78 and v0.78.1 and I just deleted v0.78 from my system so I don’t make the mistake of even looking at it.
1 Like
Also, if you are on a linux (debian based distro like ubuntu or mint) you can install platformio with apt-get install paltformio and then add yourself to the “dialout” group sudo usermod -a -G dialout <username> so you get full access to the USB port which will probably end up being /dev/ttyACM0 (you will have to log in again to get the group) At that point you can check out the github project (Maslow-Main branch) and run pio run -t upload -e usb --upload-port /dev/ttyACM0 and it will build and install the firmware, or pio run -t uploadfs -e usb --upload-port /dev/ttyACM0 to reset the filesystem (index, maslow.yaml, etc). Without the -e usb it will try to upload over wifi to maslow.local or you can specify the IP or hostname with --upload-port for that.
2 Likes
I did see the platformIO config file when I noticed all the VSCode stuff in the repo but it didn’t dawn on my to use platformio out of the cloned repo. I’ve only done similar with checking out branch versions but see the releases are ‘tagged’ so I will have to learn how to checkout the codebase for a specific tag and try that uploading.
Most of my latest esp32 work has been using a combination of the Arduino v2.x IDE and a makefile to do the filesystem flashing and sometimes building. Thanks for the heads up.
And I was considering moving from the now working v0.77 to the v0.78.1 now that we got some fixes for the oddities of moving hostnames and blinking LEDs.
1 Like
I was able to revert with this. Thank you! Haha. However, after a good config I began to jog it to setup my FIRST cut after many configs. And…after jogging a few it won’t respond. Even with a refresh.
Has anyone else run into this? Or is it a different thread? I don’t think it lost connectivity just stopped responding to jog commands.
1 Like
a new thread would probably be better
check if there are any error messages/alarms on the screen, and it wouldn’t hurt
to try refreshing the page in case it was a connectivity issue
David Lang
1 Like
It did behave ok for me today after loading the firmware this way.
2 Likes
I ran a nearly 2 hour long test tonight without issue. Router on, but no bit in it, just to see if I would have any issues. Things went very well.
2 Likes
I ran 2 very long tests on 0.78.1 yesterday (router and vacuum off, also). I got overcurrent errors on each job (different spots / times). While at the time of the failures I didn’t think the belts were overly tight, I’m thinking after sleeping on it this morning I may have picked the wrong maslow.yaml saved file I have for entering the anchor points, so I’ll try again today after making sure they are right or running another calibration.
1 Like
So I decided to run another calibration. I zeroed Z, retract/extend/hang/apply tension/calibrate.
I got this:
[MSG:INFO: All belts extended to center position]
[MSG:INFO: Measured waypoint 0]
[MSG:INFO: Center point deviation: TL: 0.346 TR: 0.103 BL: -9.229 BR: -10.888]
[MSG:INFO: Center point deviation: TL: 0.346 TR: 0.103 BL: -9.229 BR: -10.888]
[MSG:INFO: Center point deviation within 15.000mm, your coordinate system is accurate]
[MSG:INFO: Setting z-stop position]
[MSG:ERR: Unable to move safely, stopping calibration]
[MSG:ERR: Emergency stop! Stopping all motors]
[MSG:WARN: The machine will not respond until turned off and back on again]
[MSG:ERR: Unable to move safely, stopping calibration]
This is with reasonably good numbers in maslow_xxx values given I was jogging and running jobs ok with them (just hitting the overcurrent errors). I don’t understand what might be causing the checkValidMove function to trigger this estop. @bar any ideas? I’m going to do the insane thing and try the rehang dance again…
1 Like
Insanity 
– this time no error (same numbers). I’m guessing there is a value that may not be initialized correctly and causes this error to pop up on the first move in calibration? something sporadic, but I have seen this error reported in the forums several times
1 Like
Bar has said that this happens because the maslow gets confused about what it’s
supposed to do. It thinks it needs to retract a belt to move left, but the
lengths say that it needs to extend the belt.
there has been talk about disabling this error, but right now the fix is to
change the starting frame size to something larger and try again.
David Lang
1 Like
Or apparently just try again as that worked for me.
Calibration complete
Calibration values:
Fitness: 0.8985023852093569
Maslow_tlX: -52.4
Maslow_tlY: 2451.7
Maslow_trX: 2417.6
Maslow_trY: 2437.1
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 2420.3
Maslow_brY: 0.0
A command to save these values has been successfully sent for you. Please check for any error messages.
[MSG:INFO: Setting z-stop position]
[MSG:INFO: Calibration complete]
2 Likes
The issues I had with 0.78 have been cleared up with the 0.78.1 updates.
However, a couple more have cropped up when trying to Retract, Extend and Calibrate. I press Retract and get the message “[MSG:INFO: Retracting all belts]” and then go on to press Extend, getting this message: “[MSG:ERR: Please press Retract All before using Extend All]”.
This happens consistently, even after power cycling, reinstalling the new fimware.bin, maslow.yaml and index.html.gz.
I don’t know if it’s a sign of anything in particular but there’s a red light flashing the entire time on the Maslow board too.
1 Like