I updated the firmware to 0.83, but when I check the system info under the FluidNC tab, it lists as firmware 0.82. With firmware 0.82, it kept saying version 0.81 for me (making me think I was having issues updating the firmware to 0.82). Since the issue carried over with the new firmware update, I’m thinking that the firmware did in fact update and there is instead a file naming issue somewhere (likely before compiling before compiling). Do others have the same issue?
2 Likes
Interesting, can you post a screenshot of where you are seeing that number?
I’m also having an issue updating the latest firmware 0.83. I’ve gotten Error 0 a couple of tiimes. Couple of times it seems to get past 100% upload, but when the restarting countdow starts the connection gets lost.
Yes, it occurs every time I update the firmware.
2 Likes
Hi all - I also saw this behavior (startup logs, or output of $SS on GRBL console, show one firmware version behind what I installed - so after installing v0.84 I get [MSG:INFO: FluidNC v0.83 (Maslow-Main-39543985-dirty)]). It was confusing me this week while gathering notes for some troubleshooting questions/comments.
I’m pretty sure this behavior is purely “cosmetic” (albeit confusing) because the git commit hashes are correct (commit 39543985 on Maslow-Main does, in fact, have tag v0.84, commit 63b36223 has tag v0.83).
After poking around, I think the git tags may be getting added after the release is built (at least for v0.83 and v0.84 - which is where I’ve noticed the behavior). So, at release build time, git-version.py gets the previous release tag (via git describe --tags --abbrev=0). However, that tag isn’t on the head; so the latest branch and commit info are also added to the version string (because we handle the exception case following git describe --tags --exact)
@bar are you able to confirm/reject my guess? I realize it may not be high priority, but could the release process be tweaked to avoid the confusion?
I also came to the conclusion that the files were correct, but it definitely had me running in some circles trying to determine whether or not the firmware actually updated.
This sounds 100% correct to me. I tried to figure out what was going on, but I didn’t figure it out. Thank you!
I’ll make sure that in the next release I create the version number on github BEFORE running the build locally.
2 Likes
Did this happen for .85?
After updating the firmware.bin AND the yaml & index.html.gz, I see .85 in some places but still this in the “FluidNC Status” modal:
FW version: FluidNC v0.84 (Maslow-Main-3eb8feb0-dirty)
1 Like
I think so 
, I followed the new protocol of making the updated version number on GitHub before running the build, but I think I forgot to pull on the build computer 
Next time I will get it for sure!
Do you plan to re-release the artifacts for v0.85? (Not sure if next time refers to v0.86 or something before then?)
Asking because I think the issue with v0.85 isn’t just cosmetic. I suspect firmware.bin is actually missing the intended v0.85 changes because the 3eb8feb0 commit hash in the version string (from @jkleban - I get the same thing in the startup serial messages) is for the Oct 31 commit (message “typos”). That predates the Nov 6 commits that were the main content for release (specifically the commit to “Merge pull request #160 from BarbourSmith/Project-and-account-for-arm-stiffness-”).
1 Like
YES! OMG 
I will rebuild and upload a new binary right now.
I’m also updating the build checklist to do the seemingly obvious task of pulling
Edit: I’ve added 0.85.1 to the github release which should be fixed: Release V0.85 · BarbourSmith/FluidNC · GitHub
1 Like